Systems and methods for provisioning virtual internet of things universal ids (iot uids) in brownfield devices

ABSTRACT

A method for registering one or more Brownfield devices via a virtual Internet of Things Universal Identifier (IoT UID) is provided. The method includes identifying one or more Brownfield devices, generating device property data based at least in part on the one or more Brownfield devices, and transmitting, to an IoT device registrar server, a registration request that includes the device property data. The method further includes interpreting one or more IoT UIDs generated in response to the transmitting of the registration request.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims benefit of priority to U.S. Provisional PatentApplication 63/175,920, filed Apr. 16, 2021 (attorney docket referenceSMS8-0010-P01), and entitled “NETWORK CONNECTED DEVICE MANAGEMENTPLATFORM”.

The above application is hereby incorporated by reference in itsentirety.

FIELD OF INVENTION

This disclosure is related to the control and management of networkconnected devices, e.g., Internet of Things (IOT) devices.

BACKGROUND

The number of IoT devices that can collect and communicate data over anetwork, e.g., the Internet, is increasing. Many businesses use IoTdevices to track assets across supply chains and/or manufacturing lines.Many consumer goods also include IoT devices to provide “smart”functionality to end users. IoT devices, however, have lifecycles thattypically need to be managed. For example, a typical IoT device needs tobe provisioned, modified during its active life, and eventually retiredfrom use at the end of its useful life. Many traditional systems formanaging IoT devices are susceptible to attack, e.g., hacking, bymalicious actors and/or do not provide for trusted transfers of IoTdevices from one entity to another and/or across administrativeboundaries, e.g., different zones of liability and/or custody in asupply chain or other environment.

SUMMARY

Embodiments of the present disclosure provide for a registry forInternet of Things (IoT) devices that, in turn, may provide for a deviceidentity authorization process. The registry may be maintained by acentral trusted authority, e.g., a registrar, such that devices ownedand/or operated by different entities and/or user may authenticate eachother prior to interacting. Registration of an IoT device may beaccomplished via an IoT Universal Identification (IoT UID), as describedherein. A registered device may store its assigned IoT UID in the deviceitself such that the device can present its IoT UID to other devices forverification with the registrar. In embodiments, the IoT UID isassociated in a record in the registry with properties of the devicethat may be unique to the device. As such, registered devices mayexchange their IoT UIDs to learn each other's capabilities, e.g., memorycapacity, number and types of connections, processing capacity,operating system compatibility, and the like. The IoT UID may also beassociated in a record in the registry with a trust and/or riskindicator. As such, registered devices may be prohibited frominteracting with devices that do not meet a trust and/or risk levelthreshold. Thus, embodiments of the current disclosure mitigate the needfor an entity's domain controller servers to manage security groups.Such embodiments also improve the ability of a device to trust otherdevices in real-time without the need to check an approved listmaintained by the device (or its domain administrator(s)) and/or to addother devices to the approved list. Embodiments of the registry mayprovide for the ability to track the histories and/or trust and/or riskindicators of at least hundreds, thousands, hundreds of thousands,millions, billions, and/or trillions of devices.

Accordingly, various applications of apparatuses, methods, and systemsmay be provided by embodiments, including, as non-limiting examples, anIoT UID registry, a single pane of glass (SPG) system, setup of embeddedIoT UIDs for Brownfield devices, setup of embedded IoT UIDs forGreenfield devices, setup of virtual IoT UIDs for Brownfield devices,setup of virtual IoT UIDs for Greenfield devices, lifecycle managementfor registered IoT devices, tracking of a chain of title for registeredIoT devices, a dynamic trust indication/level/rating/score forregistered IoT devices, a Device Sentry for registered IoT devices, andfraud detection for registered IoT devices.

Embodiments of an IoT device registry may track and/or provide updatesand/or alerts with respect to events relating to registered IoT devices.As explained in greater detail herein, the registrar and the registryare trusted sources that can be used to determine and/or verify datarelating to an IoT device. Embodiments of the present disclosure mayprovide a database that contains records for embedded and virtual IoTUIDs. Embedded IoT UIDs may be present within an associateddevice/module and the registry. Virtual IoT UIDs may be present withinthe registry, and may not necessarily be present in an associateddevice/module. A device may include one or more modules. A module may beany type of electronic device and/or physical asset having propertiesgiving rise to a unique signature. Each module may have its own IoT UID,and each device may also have its own IoT UID in addition to those ofits modules.

As such, in an aspect of the present disclosure, there may be providedan apparatus may include an IoT UID processing circuit, a recordmanagement circuit, and a record provisioning circuit. The IoT UIDprocessing circuit may be structured to interpret an IoT UID and deviceproperty data. The record management circuit may be structured toassociate the IoT UID with the device property data via a record. Therecord provisioning circuit may be structured to transmit the record. Inembodiments, the device property data may include an owner identifiervalue, a manufacturer identifier value, a trusted platform module key, amedia access control address, a software version identifier, and/or or afirmware identifier.

In some embodiments of the present disclosure, any information managedby the IoT registry that a user wishes to access and has authority toaccess may be displayed on one display, or may be all visible at thesame time, which may be, for example, on a single display monitor oracross a multiple-monitor display system. Embodiments may determinewhich information regarding a device (or devices) and/or IoT UID islikely to be the most relevant to a particular type of user during aparticular use case. The SPG may provide a graphical user interface(GUI) for the user to interact with, such as to input data, commands,and queries, as well as to display the IoT registry data. Embodiments ofan SPG, may provide for simplified access to and/or viewing of thestatus of one or more IoT UIDs associated with a particular entity. Forexample, embodiments of an SPG may present a view of the data within theIoT device registry that is tailored to a particular user of the SPG.Thus, an SPG may provide an overview of all registered devices ownedand/or operated by an end enterprise user, and/or provide for amanufacturer to view registered devices which it made. Embodiments of anSPG may also use filtering to depict only devices and/or correspondingdevice property data to which an entity using the SPG is authorized toaccess. For example, an SPG may allow a manufacturer to view certainproperties of devices it made, but not view ownership information ofsaid devices. Similarly, an SPG may prevent a current owner of a devicefrom viewing previous ownership data of the device.

As such, in an aspect of the present disclosure, there may be providedan apparatus including a user input processing circuit structured tointerpret one or more user input command values, an Internet of ThingsUniversal Identification (IoT UID) identification circuit structured todetermine one or more IoT UIDs, based at least in part on the one ormore user input command values, a device lookup circuit structured to:generate a query that includes the one or more IoT UIDs, and retrievedevice property data corresponding to the one or more IoT UIDs, a queryprovisioning circuit structured to transmit the query to an IoT deviceregistrar server, a device property processing circuit structured tointerpret the device property data generated by the IoT device registrarserver in response to the query, and a display circuit structured todisplay the device property data with the corresponding one or more IoTUIDs.

Embodiments of the present disclosure may provide for a process ofcapturing a Brownfield device and embedding an IoT UID in it andregistering it with the registry. Such capturing may provide for apreviously untrusted device to build up its reputation, e.g., its trustlevel, over time. The process may begin with an end user using an SPGand/or some other interface to send a list of devices to the IoT deviceregistrar that they would like to register via embedded IoT UIDs. TheIoT device registrar may then generate/provision IoT UIDs, which may benew or recycled, and may transmit the list of IoT UIDs to the end userfor installation/embedding into the devices. The IoT UIDs may be storedin a database in an IoT device registry at the IoT device registrar inassociation with the device property data so that the IoT UIDs may beassociated in the registry with the device. Embodiments may wait topiggyback the provisioned IoT UIDs on an update or another type of eventor message sent to the devices via the device management platform. TheIoT UID may be stored in a writable memory device on a module of thedevice.

As such, in an aspect of the present disclosure, there may be provided amethod including identifying one or more Brownfield devices, andgenerating device property data, based at least in part on the one ormore Brownfield devices. The method may further include transmitting, toan IoT device registrar server, a registration request that includes thedevice property data, interpreting one or more IoT UIDs generated inresponse to the transmitting of the registration request, and embeddingthe one or more IoT UIDs in the one or more Brownfield devices.

Embodiments of the present disclosure may provide for a process ofinstalling IoT UIDs into Greenfield devices, which may be presale, e.g.,prior to their release from a manufacturer for use by end users, orpost-sale, e.g., when an end user turns the device on after purchasingfrom the manufacturer. In a non-limiting pre-sale example, amanufacturer may send device property data for newly-minted devicesand/or modules to a device management platform, that then may relay thedata to the IoT device registrar, which may generate and send the IoTUIDs to the device management platform, which may then provide them tothe manufacturer for installation into the Greenfield devices beforethey are released to end users. The IoT UIDs may be stored in a databasein an IoT device registry at the IoT device registrar in associationwith the device property data so that the IoT UIDs may be associated inthe registry with the device. Embodiments may provide for abootstrapping IoT UID registration process, which may occur pre-sale orpost-sale. Embodiments may provide for batch registration ofnewly-minted Greenfield devices. Embodiments may provide for a device tobe “claimed” upon activation by an end user before registration canproceed, which may include updating ownership information stored in theregistry, updating a chain of title stored in the registry, etc.Registering a Greenfield device with the registry may provide forverification of the Greenfield device's entire history.

As such, in an aspect of the present disclosure, there may be provided amethod including manufacturing one or more Greenfield devices, andgenerating device property data based at least in part on the one ormore Greenfield devices. The method may further include transmitting, toan IoT device registrar server, a registration request that includes thedevice property data. The method may further include interpreting one ormore IoT UIDs generated in response to the transmitting of theregistration request. The method may further include embedding the oneor more IoT UIDs in the one or more Greenfield devices.

Embodiments of the present disclosure may provide for a process ofcapturing a Brownfield device, generating an IoT UID for the Brownfielddevice, and registering it with the IoT device registry withoutembedding the IoT UID into the Brownfield device, i.e., the IoT UID forthe device may be virtual. For example, a virtual IoT UID may be used inscenarios in which a manufacturer and/or end user does not want tomanage the presence of an embedded IoT UID. In embodiments a virtual IoTUID may be generated using a combination of device attributes, e.g.,device property data, such that the virtual IoT UID may uniquelycorrespond to a particular device. The IoT device registry may associatedevice property data for the Brownfield device with the IoT UIDs in arecord in an IoT registry. In a non-limiting scenario, a company withexisting unregistered devices may want to track said devices withvirtual IoT UIDs. The process may begin with an end user using an SPGand/or some other interface to send a list of devices with correspondingdevice property data to the IoT device registrar that they would like toregister via virtual IoT UIDs. The IoT device registrar may thengenerate/provision IoT UIDs, which may be new or recycled, and then maypair each IoT UID to a specific set of the device property datacorresponding to a particular device. In embodiments, the IoT deviceregistrar may send a notification back to a device management platformindicating that the devices have been registered. Registering aBrownfield device may improve its trust indicator/rating/level/scorevalue as recorded in its associated record in the IoT device registry.Embodiments may provide for the registration process to be initiated bya device management platform when a Brownfield device is added to thedevice management platform.

As such, in an aspect of the present disclosure, there may be provided amethod including identifying one or more Brownfield devices, generatingdevice property data based at least in part on the one or moreBrownfield devices, and transmitting, to an IoT device registrar server,a registration request that includes the device property data. Themethod may further include interpreting one or more IoT UIDs generatedin response to the transmitting of the registration request.

Embodiments of the present disclosure may provide for a process ofregistering Greenfield devices with virtual IoT UIDs, which may bepresale, e.g., prior to their release from a manufacturer for use by endusers, or post-sale, e.g., when an end user turns the device on afterpurchasing from the manufacturer. For example, a virtual IoT UID may beused in scenarios in which a manufacturer and/or end user does not wantto manage the presence of an embedded IoT UID. In a non-limitingpre-sale example, a manufacturer may send device property data fornewly-minted devices (and/or modules) to a device management platform,that then may relay the data to the IoT device registrar, which maygenerate IoT UIDs and associate each of them with portions of the deviceproperty data corresponding to one of the Greenfield devices to beregistered in a record in an IoT registry. The IoT device registrar maythen send a notification back to the device management platform that thedevices have been registered. Embodiments may provide for abootstrapping IoT UID registration process, which may occur pre-sale orpost-sale. In a non-limiting example of the bootstrap registrationprocess, a manufacturer (e.g., pre-sale) or an end user (e.g.,post-sale) may boot up a newly-minted Greenfield device, which may thenproceeds to contact the device management platform, which may thenrequest the IoT device registrar to register the Greenfield device via avirtual IoT UID. Embodiments may provide for batch registration ofnewly-minted Greenfield devices. Embodiment may provide for a device tobe “claimed” upon activation by an end user before registration canproceed, which may include updating ownership information stored in theregistry, updating a chain of title stored in the registry, etc.

As such, in an aspect of the present disclosure, there may be provided amethod including identifying one or more Greenfield devices, generatingdevice property data based at least in part on the one or moreGreenfield devices, and transmitting, to an IoT device registrar server,a registration request that includes the device property data. Themethod may further include interpreting one or more IoT UIDs generatedin response to the transmitting of the registration request.

Embodiments of the present disclosure may provide for lifecyclemanagement for registered IoT devices. Examples of lifecycle managementmay include performing status checks of devices and their currentconfiguration states, e.g., installed patches, installed hardware,number of active network cards, etc. Lifecycle management may includedetecting changes in the properties of a device, e.g., detecting and/orrecording events. Events may come from a device manager, connectionmanagement platform (CMP), a Remote Authentication Dial-In User Service(RADIUS) feed (e.g., event stream), and/or a Home Location Register(HLR). Lifecycle management may include detecting security events.Lifecycle management may include tracking of ownership changes in theIoT device registry. Embodiments may provide for retirement ofGreenfield and/or Brownfield devices. Embodiments may monitor forinstances in which a permanently retired immutable device property,e.g., an International Mobile Equipment Identity (IMEI), appears inanother device. Embodiments may provide forreincarnation/reuse/recycling of old IoT UIDs and/or for their permanentretirement. Embodiments may provide for checks on whether datacollection makes sense. Down detection may be provided by certainembodiments. Embodiments may facilitate the pushing of updates and/orpatches to devices. Lifecyle management may include modifying a trustindicator/rating/level/score of a device based on events. Embodimentsmay decrease/lower/reduce/drop a device's trustindicator/rating/level/score if the corresponding information in the IoTdevice registry starts to get stale, for example, if it has not beenupdated and/or queried for at least a predetermined time. Embodimentsmay provide for polling of devices to provide updates to their storedproperty data.

As such, in an aspect of the present disclosure, there may be providedan apparatus including a property-monitoring circuit structured togenerate a query for device property data for an IoT device to an IoTdevice registrar server, interpret the device property data receivedfrom the IoT device registrar server to determine whether there is achange in the device property data, if the property-monitoring circuitdetermines that there is a change in the device property data, generatea notification of the change, and transmit the notification of thechange to the IoT device registrar server.

Embodiments of the present disclosure may provide for themaintaining/recording of chain of title for devices. Maintaining and/orrecording of the chain of title may be provided via a distributedledger, e.g., a blockchain. Embodiments may provide for certificationthat a device is not a stolen device and/or has a fully accountablechain of title. Certification may be used to evaluate an asking pricefor a registered device, or for a group of devices that may include oneor more registered devices. Embodiments provide for an entity to claimownership of a device. The trust indicator/rating/level/score may benumeric based, color based, symbol based, alphanumeric based, letterbased, or any combination thereof. Non-limiting examples of eventsresulting in title changes include: creation of a device, sale of adevice, decommissioning of a device, license of a device, etc.Embodiments may provide for supply chain validation. As non-limitingexamples, validation may include determining whether device modules weresourced from authorized vendors, or from fair trade certified sources.Embodiments may provide for determining a carbon rating of a devicebased on known ratings of their modules' sources. Embodiments mayprovide for the detection of device properties, e.g., location, usageprofile, network, interface language, device settings, associatedtelephone number, that may be indicative of a change in ownership.

As such, in an aspect of the present disclosure, there may be providedan apparatus including an IoT UID processing circuit, a recordmanagement circuit, an ownership analysis circuit, and an ownershipprovisioning circuit. The IoT UID processing circuit may be structuredto interpret an IoT UID corresponding to a device. The record managementcircuit may be structured to identify, based at least in part on the IoTUID, a record in a database, the record including device ownership dataassociated with the device. The ownership analysis circuit may bestructured to interpret, based at least in part on the record, thedevice ownership data associated with the device. The ownershipprovisioning circuit may be structured to transmit the device ownershipdata.

Embodiments of the present disclosure may provide for a rating of the“trustworthiness” of a device, which may be capable of changing overtime as the device experiences “life” events, e.g., ecosystem events.For example, Greenfield devices may automatically start out with a highvalue trust indicator/rating/level/score because their whole existencehistory may be known and verifiable. The trustindicator/rating/level/score may be numeric based, color based, symbolbased, alphanumeric based, letter based, or any combination thereof. Atrust indicator (e.g., trust rating/level/score value) may decrease assoftware/hardware grows older and/or out of date. Patching may improve adevice's trust indicator. Trust indicators may be determined, in part,by device location, e.g., geo-fenced trust indicators. Embodiments mayprovide for user-defined scores and/or scales. Scores may be convertedfrom one paradigm/entity to another, in which the IoT device registrymay serve as a baseline score to which the others can be compared.Embodiments may provide for trust indicators for online servers toinclude game/metaverse servers. Embodiments may provide for augmentedreality (AR) trust indicators to be shown in relation to devices, e.g.,ATM and/or card readers, in the real world. Trust indicators may beapplied to device manufacturers.

As such, in an aspect of the present disclosure, there may be providedan apparatus including an IoT UID processing circuit structured tointerpret an IoT UID corresponding to a device, a record managementcircuit structured to identify, based at least in part on the IoT UID, arecord in a database corresponding to the device, a trust analysiscircuit structured to determine, based at least in part on the record, arisk indicator of the device, and an indicator provisioning circuitstructured to transmit the risk indicator.

Embodiments of the present disclosure may provide for risk and/or trustscores/indicators and/or certification of servers and/or other physicalassets supporting metaverse activities. For example, a user in themetaverse may be provided with a risk score of a server before enteringan area (e.g., a room) in the metaverse hosted by that server.Embodiments may provide for risk scores of users within the metaverse.Such risk score may be based on the risk score of devices associatedwith the user. Embodiments may depict/express the risk scores within themetaverse as a trust indicator/rating/level/score that may be numericbased, color based, symbol based, alphanumeric based, letter based, orany combination thereof. Embodiments of the disclosure may provide foran end user application that restricts a user from accessing orinteracting with a device/entity in the metaverse, for example, adevice, a server, an area, an object, an avatar, or another user, thatdoes not meet a minimum risk threshold and/or does not present acertification. Embodiments of the application may be a parental controlsoftware agent. The risk scores may be determined, stored, and/ormaintained by an IoT UID device registrar, e.g., in an IoT deviceregistrar server. A device may be a virtual device (an object in themetaverse having a real-world counterpart, e.g., a real-world devicecounterpart), a real-world device (an object in the real-world having ametaverse counterpart), or a meta-device (an object in the metaverselacking a real-world counterparts or, in some instances, having one ormore real-world counterparts). A device may include virtual devices andmeta-devices. A virtual device may be a digital twin of a real-worlddevice. The risk and/or trust indicator/rating/level/score may betailored to a user. Trust and/or risk scores may be shown with respectto a virtual store for metaverse purchases.

As such, in an aspect of the present disclosure, there may be providedan apparatus including an IoT UID processing circuit, a recordmanagement circuit, a trust analysis circuit, and a trust indicatorprovisioning circuit. The IoT UID processing circuit may be structuredto interpret an IoT UID corresponding to a device in a metaverse. Therecord management circuit may be structured to identify, based at leastin part on the IoT UID, a record in a database corresponding to thedevice in the metaverse. The trust analysis circuit may be structured todetermine, based at least in part on the record, a trust indicator ofthe device in the metaverse. The trust indicator provisioning circuitmay be structured to transmit the trust indicator.

Embodiments of the present disclosure may provide for the depiction anduse of a risk and/or trust indicator/rating/level/score and/orcertification via augmented reality (AR). Embodiments may depictrisk/trust scores of objected encountered by a user. As a non-limitingexample, a user wearing an AR device, such as an AR headset, AR contactlenses, AR glasses, or AR goggles, may see an ATM colored green if thedevice has a sufficiently high trust indicator (e.g., trustscore/rating/level value), or red if the device has a sufficiently lowtrust indicator. Embodiments may depict trust indicators for individualsbased on the trust indicators of devices associated with the scoredindividuals. Devices may be virtual devices, real-world devices, ormeta-devices. Applications of the trust and/or risk scores may be usedfor virtual stores in a metaverse.

As such, in an aspect of the present disclosure, there may be providedan apparatus including an IoT UID processing circuit structured tointerpret an IoT UID corresponding to a device in an AR, a recordmanagement circuit structured to identify, based at least in part on theIoT UID, a record in a database corresponding to the device in the AR, atrust analysis circuit structured to determine, based at least in parton the record, a trust indicator of the device in the AR, a trustindicator provisioning circuit structured to transmit the trustindicator.

Embodiments of the present disclosure may provide for an agent thatmonitors registered devices for known vulnerabilities and providesalerts and/or access to remedial measures, e.g., patches. The agent mayexecute on the same system as the IoT device registry and/or on a systemowned and/or operated by an end user, manufacturer, and/or devicemanagement platform. Embodiments may provide for the collection ofremedial measures from a device manufacturer and/or other source, e.g.,the National Security Agency (NSA), Linux Distros, Microsoft, Apple,Google, etc., and may provide the generation of campaigns to manageand/or track implementing the remedial action of a plurality of affecteddevices, e.g., “software Bill of Materials (SBoM)” and/or “CybersecurityBill of materials (CBoM).” Embodiments may provide for the aggregationof hardware and/or software version data, which the agent may use todetect vulnerabilities. Embodiments may access a vulnerability database.Embodiments may generate a vulnerability database. The agent/sentry maysend an alert when it detects a configuration change of a module, e.g.,when a new network interface controller (NIC) has been installed. Inembodiments, the agent/sentry may poll and/or otherwise monitor securitysources for relevant information and automatically generate matches,generate alerts/notifications, and/or highlight potentially affecteddevices (via an alert and/or event message, which may be in an SPG, asdisclosed herein) to device users, administrators, manufacturers, etc.In embodiments, the agent/sentry may change/adjust the trust and/or risklevels of the affected devices, e.g., decrease the trust levels (orincrease the risk levels) where the devices fall out of compliance dueto a new patch. Once action is taken to remedy the vulnerabilities, thetrust and/or risk levels will revert to the relevant trust and/or risklevel and/or security state. In embodiments, the agent/sentry maymaintain audited logs of actions taken to address the vulnerabilities.

As such, in an aspect of the present disclosure, there may be providedan apparatus including a device property data processing circuitstructured to: at a first time, interpret, device property datacorresponding to a device registered with an IoT device registry, and ata second time, interpret, the device property data corresponding to thedevice registered with the IoT device registry, a change detectioncircuit structured to detect a change in the device property databetween the first time and the second time, an alert circuit structuredto generate, responsive to the detected change, a message thatidentifies the device corresponding to the device property data, and analert provisioning circuit structured to transmit the message.

Embodiments of the present disclosure may provide for an agent thatmonitors registered devices for loss of one or more network connections.Monitoring may be for a single device and/or for multiple devices, e.g.,a fleet of devices. The agent may not necessarily be concerned withhardware and/or software version of components; rather, the agent maylook at the IoT device registry to detect outage patterns. The IoTdevice registrar may be in a unique position to view a large number ofdevices simultaneously, which may provide for greater insight into theexistence of a device outage.

As such, in an aspect of the present disclosure, there may be providedan apparatus including a device property data processing circuit, anoutage detection circuit, an alert circuit, and an alert provisioningcircuit. The device property data processing circuit may be structuredto interpret device property data corresponding to one or more devicesregistered with an IoT device registry. The outage detection circuit maybe structured to detect an outage pattern in the device property data.The outage pattern may correspond to an outage of the one or moredevices. The alert circuit may be structured to, responsive to theoutage pattern, generate an alert message that identifies the one ormore devices. The alert provisioning circuit may be structured totransmit the alert message.

Embodiments of the present disclosure may provide for an agent thatmonitors the IoT device registry for signs of fraudulent activity. Thismay provide for detection of unusual behavior that may be indicative offraud and/or a security risk. Correlation of device properties acrossthe various spectrums may provide for a unique ability to detect unusualrelationships that may indicate fraud and/or warrant furtherinvestigation. Embodiments may send messages to various parties, e.g.,manufacturers that may include restricted views of device property data,which may enable the various parties to detect unusual behavior and/orfraud.

As such, in an aspect of the present disclosure, there may be providedan apparatus including a device property data processing circuit, asecurity analysis circuit, an alert circuit, and an alert provisioningcircuit. The device property data processing circuit may be structuredto interpret device property data corresponding to a device registeredwith an IoT device registry. The security analysis circuit may bestructured to determine, based at least in part on the device propertydata, that the device is subject to a fraud event. The alert circuit maybe structured to generate, responsive to the determined fraud event, amessage that identifies the device. The alert provisioning circuit maybe structured to transmit the message.

Embodiments of the present disclosure may provide for the registering ofmeta-devices with the IoT UID registry. A meta-device, in embodiments,may be a device and/or module that exists in a computer environment,e.g., a metaverse, a virtual environment apart from a metaverse, asoftware object, etc. A meta-device may have one or more real-worldcounterparts, or no real-world counterpart. A meta-device with at leastone real-world counterpart may be a virtual device. A meta-device mayhave a set of properties forming a unique signature for the meta-device,e.g., device property data, which may include one or more non-fungibletokens (NFTs). A meta-device may be a Greenfield device and/or aBrownfield device. A non-limiting use case of registering a meta-deviceincludes a programmer registering a newly programmed and instantiatedcar for use in a multi-player/avatar virtual environment, e.g., ameta-verse, with an IoT device registrar as a Greenfield meta-device.The car may then be purchased by a user/customer, and then eventmessages may be transmitted to the IoT device registrar to track thelife cycle events of the car. The car may also have a NFT, which may bestored by the registry as part of the device property data. Inembodiments, a meta-device may be a point-of-sale device in a virtualconvenience store where the meta-device may correspond to multiplereal-world devices that are not real-world point-of-sale devices, e.g.,a server, payment gateway, and/or a firewall.

As such, in an aspect of the present disclosure, there may be providedan apparatus including an IoT UID processing circuit structured tointerpret an IoT UID and device property data corresponding to ameta-device, a record management circuit structured to associate the IoTUID with the device property data via a record, and a recordprovisioning circuit structured to transmit the record.

The description herein references various applications as non-limitingexamples of apparatuses, methods, and systems, and for clarity of thepresent description. However, embodiments herein are applicable to otherapplications having similar challenges and/or implementations.

Additional features and advantages of the invention will be set forth inthe description which follows, and in part will be apparent from thedescription, or may be learned by practice of the invention. Theobjectives and other advantages of the invention will be realized andattained by the structure particularly pointed out in the writtendescription and claims hereof as well as the appended drawings.

For the purposes of promoting an understanding of the principles of thedisclosure, reference will now be made to the embodiments illustrated inthe drawings and described in the following written specification. It isunderstood that no limitation to the scope of the disclosure is therebyintended. It is further understood that the present disclosure includesany alterations and modifications to the illustrated embodiments andincludes further applications of the principles disclosed herein aswould normally occur to one skilled in the art to which this disclosurepertains. It is to be understood that both the foregoing generaldescription and the following detailed description are examples andexplanatory and are intended to provide further explanation of theinvention as claimed.

BRIEF DESCRIPTION OF THE FIGURES

For the purposes of promoting an understanding of the principles of thedisclosure, reference will now be made to the embodiments illustrated inthe figures and described in the following written specification. It isunderstood that no limitation to the scope of the disclosure is therebyintended. It is further understood that the present disclosure includesany alterations and modifications to the illustrated embodiments andincludes further applications of the principles disclosed herein aswould normally occur to one skilled in the art to which this disclosurepertains. Further, skilled artisans will appreciate that elements in thefigures are illustrated for simplicity and clarity and may notnecessarily be drawn to scale. For example, the dimensions of some ofthe elements in the figures may be exaggerated relative to otherelements to help to improve understanding of embodiments of the methodsand systems disclosed herein. Accordingly:

FIG. 1 is a schematic diagram of a system for managing one or moredevices, in accordance with an embodiment of the current disclosure;

FIG. 2 is a component diagram of a system for managing one or moredevices, in accordance with an embodiment of the current disclosure;

FIG. 3 is a schematic diagram of another embodiment of a system formanaging one or more devices, in accordance with the current disclosure;

FIG. 4 is a block diagram of another embodiment of a system for managingone or more devices, in accordance with the current disclosure;

FIG. 5 is a block diagram of an Internet of Things Universal Identifier,in accordance with an embodiment of the current disclosure;

FIG. 6 is a block diagram of data types for providing and Internet ofThings (IoT) device registry, in accordance with an embodiment of thecurrent disclosure;

FIG. 7 is a diagram depicting an IoT Universal Identifier (IoT UID), inaccordance with an embodiment of the current disclosure;

FIG. 8 is a schematic diagram of an apparatus for managing networkconnected devices, in accordance with an embodiment of the currentdisclosure;

FIG. 9 is a flowchart depicting a method for managing network connecteddevices, in accordance with an embodiment of the current disclosure;

FIG. 10 is another flowchart depicting a method for managing networkconnected devices, in accordance with an embodiment of the currentdisclosure;

FIG. 11 is schematic diagram of an apparatus for registering devices, inaccordance with an embodiment of the current disclosure;

FIG. 12 is another schematic diagram of an apparatus for registeringdevices, in accordance with an embodiment of the current disclosure;

FIG. 13 is a flowchart depicting a method for registering devices, inaccordance with an embodiment of the current disclosure;

FIG. 14 is another flowchart depicting a method for registering devices,in accordance with an embodiment of the current disclosure;

FIG. 15 is another schematic diagram of an apparatus for registeringdevices, in accordance with an embodiment of the current disclosure;

FIG. 16 is another schematic diagram of an apparatus for registeringdevices, in accordance with an embodiment of the current disclosure;

FIG. 17 is another flowchart depicting a method for registering devices,in accordance with an embodiment of the current disclosure;

FIG. 18 is another flowchart depicting a method for registering devices,in accordance with an embodiment of the current disclosure;

FIG. 19 is a schematic diagram of an apparatus for an Internet of Things(IoT) device registry display, in accordance with an embodiment of thecurrent disclosure;

FIG. 20 is a flowchart depicting a method for an IoT device registrydisplay, in accordance with an embodiment of the current disclosure;

FIG. 21 is a flowchart depicting a method for an IoT device registrydisplay, in accordance with an embodiment of the current disclosure;

FIG. 22 is a schematic diagram of a system for an IoT device registrydisplay, in accordance with an embodiment of the current disclosure;

FIG. 23 is a schematic diagram of an apparatus for an IoT deviceregistry display, in accordance with an embodiment of the currentdisclosure;

FIG. 24 is a flowchart depicting a method for an IoT device registrydisplay, in accordance with an embodiment of the current disclosure;

FIG. 25 is a flowchart depicting a method for an IoT device registrydisplay, in accordance with an embodiment of the current disclosure;

FIG. 26 is a flowchart depicting a method for an IoT device registrydisplay, in accordance with an embodiment of the current disclosure;

FIG. 27 is a schematic diagram of an apparatus for an IoT deviceregistry display, in accordance with an embodiment of the currentdisclosure;

FIG. 28 is a diagram of graphical user interfaces for an IoT deviceregistry display, in accordance with an embodiment of the currentdisclosure;

FIG. 29 is a schematic diagram of an architecture for implementingtrusted relationships between entities, in accordance with an embodimentof the current disclosure;

FIG. 30 is a process flow diagram depicting process flows for embeddingIoT UIDs into Brownfield devices, in accordance with embodiments of thecurrent disclosure;

FIG. 31 is a process flow diagram depicting registration of a Brownfielddevice with an IoT device registrar, in accordance with an embodiment ofthe current disclosure;

FIG. 32 is schematic diagram of an apparatus for provisioning embeddedIoT UIDs in Brownfield devices, in accordance with an embodiment of thecurrent disclosure;

FIG. 33 is another schematic diagram of an apparatus for provisioningembedded IoT UIDs in Brownfield devices, in accordance with anembodiment of the current disclosure;

FIG. 34 is a flowchart depicting a method for provisioning embedded IoTUIDs in Brownfield devices, in accordance with an embodiment of thecurrent disclosure;

FIG. 35 is a schematic diagram of an apparatus for provisioning embeddedIoT UIDs in Brownfield devices, in accordance with an embodiment of thecurrent disclosure;

FIG. 36 is a flowchart depicting a method for provisioning embedded IoTUIDs in Brownfield devices, in accordance with an embodiment of thecurrent disclosure;

FIG. 37 is another flowchart depicting a method for provisioningembedded IoT UIDs in Brownfield devices, in accordance with anembodiment of the current disclosure;

FIG. 38 is another flowchart depicting a method for provisioningembedded IoT UIDs in Brownfield devices, in accordance with anembodiment of the current disclosure;

FIG. 39 is another schematic diagram of an apparatus for provisioningembedded IoT UIDs in Brownfield devices, in accordance with anembodiment of the current disclosure;

FIG. 40 is a process flow diagram depicting process flows for embeddingIoT UIDs into Greenfield devices, in accordance with embodiments of thecurrent disclosure;

FIG. 41 is a process flow diagram for provisioning Greenfield deviceshaving embedded IoT UIDs with a cloud platform, in accordance with anembodiment of the current disclosure;

FIG. 42 is a flowchart depicting a method for embedding IoT UIDs intoone or more Greenfield devices, in accordance with an embodiment of thecurrent disclosure;

FIG. 43 is another flowchart depicting a method for embedding IoT UIDsinto one or more Greenfield devices, in accordance with an embodiment ofthe current disclosure;

FIG. 44 is a flowchart depicting a method for embedding an IoT UID intoa Greenfield device, in accordance with an embodiment of the currentdisclosure;

FIG. 45 is another flowchart depicting a method for embedding an IoT UIDinto a Greenfield device, in accordance with an embodiment of thecurrent disclosure;

FIG. 46 is a schematic diagram of an apparatus that initiates abootstrap process for registering with an IoT device registrar, inaccordance with an embodiment of the current disclosure;

FIG. 47 is another schematic diagram of an apparatus that at initiates abootstrap process for registering with an IoT device registrar, inaccordance with an embodiment of the current disclosure;

FIG. 48 is a flowchart depicting another method of embedding an IoT UIDinto a Greenfield device, in accordance with an embodiment of thecurrent disclosure;

FIG. 49 is a schematic diagram of an apparatus for registering aGreenfield device with an IoT device registrar, in accordance with anembodiment of the current disclosure;

FIG. 50 is a flowchart depicting a method of registering a Greenfielddevice with an IoT device registrar, in accordance with an embodiment ofthe current disclosure;

FIG. 51 is a process flow diagram depicting a process for registeringone or more Brownfield devices via a virtual Internet of ThingsUniversal Identifier (IoT UID), in accordance with an embodiment of thecurrent disclosure;

FIG. 52 is another process flow diagram depicting a process forregistering one or more Brownfield devices via a virtual IoT UID, inaccordance with an embodiment of the current disclosure;

FIG. 53 is a schematic diagram of an apparatus for registering one ormore Brownfield devices via a virtual IoT UID, in accordance with anembodiment of the current disclosure;

FIG. 54 is another schematic diagram of an apparatus for registering oneor more Brownfield devices via a virtual IoT UID, in accordance with anembodiment of the current disclosure;

FIG. 55 is a flowchart depicting a method for registering one or moreBrownfield devices via a virtual IoT UID, in accordance with anembodiment of the current disclosure;

FIG. 56 is another flowchart depicting a method for registering one ormore Brownfield devices via a virtual IoT UID, in accordance with anembodiment of the current disclosure;

FIG. 57 is another schematic diagram of an apparatus for registering oneor more Brownfield devices via a virtual IoT UID, in accordance with anembodiment of the current disclosure;

FIG. 58 is another schematic diagram of an apparatus for registering oneor more Brownfield devices via a virtual IoT UID, in accordance with anembodiment of the current disclosure;

FIG. 59 is another flowchart depicting a method for registering one ormore Brownfield devices via a virtual IoT UID, in accordance with anembodiment of the current disclosure;

FIG. 60 is another flowchart depicting a method for registering one ormore Brownfield devices via a virtual IoT UID, in accordance with anembodiment of the current disclosure;

FIG. 61 is a process flow diagram depicting a process for registeringone or more Greenfield devices via a virtual Internet of ThingsUniversal Identifier (IoT UID), in accordance with an embodiment of thecurrent disclosure;

FIG. 62 is another process flow diagram depicting a process forregistering one or more Greenfield devices via a virtual IoT UID, inaccordance with an embodiment of the current disclosure;

FIG. 63 is a process flow diagram depicting a process for registeringone or more Greenfield devices via a virtual Internet of ThingsUniversal Identifier (IoT UID), in accordance with an embodiment of thecurrent disclosure;

FIG. 64 is schematic flow chart of a method for registering one or moreGreenfield devices via a virtual Internet of Things Universal Identifier(IoT UID);

FIG. 65 is schematic flow chart of a method for registering one or moreGreenfield devices via a virtual Internet of Things Universal Identifier(IoT UID);

FIG. 66 is schematic flow chart of a method for registering one or moreGreenfield devices via a virtual Internet of Things Universal Identifier(IoT UID);

FIG. 67 is schematic depiction of a system for registering one or moreGreenfield devices via a virtual Internet of Things Universal Identifier(IoT UID);

FIG. 68 is schematic depiction of an apparatus for registering one ormore Greenfield devices via a virtual Internet of Things UniversalIdentifier (IoT UID);

FIG. 69 is a schematic diagram of an apparatus for an Internet of Things(IoT) device registry, in accordance with an embodiment of the currentdisclosure;

FIG. 70 is a flowchart depicting a method for an IoT device registry, inaccordance with an embodiment of the current disclosure;

FIG. 71 is another flowchart depicting a method for an IoT deviceregistry, in accordance with an embodiment of the current disclosure;

FIG. 72 is a flowchart depicting a method for an IoT device registry, inaccordance with an embodiment of the current disclosure;

FIG. 73 is another flowchart depicting a method for an IoT deviceregistry, in accordance with an embodiment of the current disclosure;

FIG. 74 is a schematic diagram of an apparatus for an IoT deviceregistry, in accordance with an embodiment of the current disclosure;

FIG. 75 is a flowchart depicting a method for an IoT device registry, inaccordance with an embodiment of the current disclosure;

FIG. 76 is a schematic diagram of an apparatus for an IoT deviceregistry, in accordance with an embodiment of the current disclosure;

FIG. 77 is a flowchart depicting a method for an IoT device registry, inaccordance with an embodiment of the current disclosure;

FIG. 78 is a schematic diagram of an apparatus for an IoT deviceregistry, in accordance with an embodiment of the current disclosure;

FIG. 79 is a schematic diagram of an apparatus for an IoT deviceregistry, in accordance with an embodiment of the current disclosure;

FIG. 80 is a schematic diagram depicting a lifecycle of networkconnected devices, in accordance with an embodiment of the currentdisclosure;

FIG. 81 is a diagram mapping features to benefits of the system of FIG.1, in accordance with an embodiment of the current disclosure;

FIG. 82 is a process flow diagram depicting process flows for lifecyclemanagement of IoT devices, in accordance with embodiments of the currentdisclosure;

FIG. 83 is another process flow diagram depicting process flows forlifecycle management of IoT devices, in accordance with embodiments ofthe current disclosure;

FIG. 84 is another process flow diagram depicting process flows forlifecycle management of IoT devices, in accordance with embodiments ofthe current disclosure;

FIG. 85 is a component diagram of a system for managing one or moredevices, in accordance with an embodiment of the current disclosure;

FIG. 86 is a schematic diagram of an apparatus for an Internet of Things(IoT) device registry, in accordance with an embodiment of the currentdisclosure;

FIG. 87 is a schematic diagram of an apparatus for an IoT deviceregistry, in accordance with an embodiment of the current disclosure;

FIG. 88 is a schematic diagram of an apparatus for an IoT deviceregistry, in accordance with an embodiment of the current disclosure;

FIG. 89 is a flowchart depicting a method for an IoT device registry, inaccordance with an embodiment of the current disclosure;

FIG. 90 is a flowchart depicting a method for an IoT device registry, inaccordance with an embodiment of the current disclosure;

FIG. 91 is a flowchart depicting a method for an IoT device registry, inaccordance with an embodiment of the current disclosure;

FIG. 92 is a schematic diagram of a system for an IoT device registry,in accordance with an embodiment of the current disclosure;

FIG. 93 is a flowchart depicting a method for an IoT device registry, inaccordance with an embodiment of the current disclosure;

FIG. 94 is a flowchart depicting a method for an IoT device registry, inaccordance with an embodiment of the current disclosure;

FIG. 95 is a schematic diagram of an apparatus for an IoT deviceregistry, in accordance with an embodiment of the current disclosure;

FIG. 96 is a schematic diagram of a system for an IoT device registry,in accordance with an embodiment of the current disclosure;

FIG. 97 is a flowchart depicting a method for transmitting a riskindicator, in accordance with an embodiment of the current disclosure;

FIG. 98 is a schematic diagram of an apparatus for transmitting a riskindicator, in accordance with an embodiment of the current disclosure;

FIG. 99 is another flowchart depicting a method of interpreting a trustindicator, in accordance with an embodiment of the current disclosure;

FIG. 100 is a schematic diagram of an apparatus for interpreting a trustindicator, in accordance with an embodiment of the current disclosure;

FIG. 101 is a flowchart depicting a method for managing interactionswith devices in a metaverse, in accordance with an embodiment of thecurrent disclosure;

FIG. 102 is a block diagram depicting an apparatus for managinginteractions with devices in a metaverse, in accordance with anembodiment of the current disclosure;

FIG. 103 is a flowchart depicting a method for managing interactionswith devices in a metaverse, in accordance with an embodiment of thecurrent disclosure;

FIG. 104 is a block diagram depicting an apparatus for managinginteractions with devices in a metaverse, in accordance with anembodiment of the current disclosure;

FIG. 105 is a flowchart depicting a method for managing interactionswith devices via Augmented Reality Applications, in accordance with anembodiment of the current disclosure;

FIG. 106 is a block diagram depicting an apparatus for managinginteractions with devices via Augmented Reality Applications, inaccordance with an embodiment of the current disclosure;

FIG. 107 is a flowchart depicting a method for managing interactionswith devices via Augmented Reality Applications, in accordance with anembodiment of the current disclosure;

FIG. 108 is a block diagram depicting an apparatus for managinginteractions with devices via Augmented Reality Applications, inaccordance with an embodiment of the current disclosure;

FIG. 109 is a flowchart depicting a method for monitoring records in aninternet of things (IoT) device registry for changes in device propertydata, in accordance with an embodiment of the current disclosure;

FIG. 110 is a flowchart depicting a method for monitoring records in anIoT device registry for changes in device property data, in accordancewith an embodiment of the current disclosure;

FIG. 111 is a block diagram depicting an apparatus for monitoringrecords in an IoT device registry for changes in device property data,in accordance with an embodiment of the current disclosure;

FIG. 112 is a block diagram depicting a system for monitoring records inan IOT device registry for changes in device property data, inaccordance with an embodiment of the current disclosure;

FIG. 113 is a flowchart depicting a method for monitoring records in anIoT device registry for changes in device property data, in accordancewith an embodiment of the current disclosure;

FIG. 114 is a block diagram depicting an apparatus for monitoringrecords in an IoT device registry for changes in device property data,in accordance with an embodiment of the current disclosure;

FIG. 115 is a schematic diagram of an apparatus for detecting downdevices, in accordance with an embodiment of the current disclosure;

FIG. 116 is another schematic diagram of an apparatus for detecting downdevices, in accordance with an embodiment of the current disclosure;

FIG. 117 is a flowchart depicting a method for detecting down devices,in accordance with an embodiment of the current disclosure;

FIG. 118 is another flowchart depicting a method for detecting downdevices, in accordance with an embodiment of the current disclosure;

FIG. 119 is a flowchart depicting a method for training an artificialintelligence (AI) to detect device outages, in accordance with anembodiment of the current disclosure;

FIG. 120 is a schematic diagram of an apparatus for detecting fraudulentactivity, in accordance with an embodiment of the current disclosure;

FIG. 121 is a flowchart depicting a method for detecting fraudulentactivity, in accordance with an embodiment of the current disclosure;

FIG. 122 is a flowchart depicting a method for detecting fraudulentactivity, in accordance with an embodiment of the current disclosure;

FIG. 123 is a flowchart depicting a method for detecting fraudulentactivity, in accordance with an embodiment of the current disclosure;

FIG. 124 is a schematic diagram of an apparatus for detecting fraudulentactivity, in accordance with an embodiment of the current disclosure;

FIG. 125 is a flowchart depicting a method for detecting fraudulentactivity, in accordance with an embodiment of the current disclosure;

FIG. 126 is a flowchart depicting a method for detecting fraudulentactivity, in accordance with an embodiment of the current disclosure;

FIG. 127 is a schematic diagram of a system for detecting fraudulentactivity, in accordance with an embodiment of the current disclosure;

FIG. 128 is a flowchart depicting a method for detecting fraudulentactivity, in accordance with an embodiment of the current disclosure;

FIG. 129 is a flowchart depicting a method for detecting fraudulentactivity, in accordance with an embodiment of the current disclosure;

FIGS. 130-135 are flowcharts depicting methods for registeringmeta-devices with an Internet of Things (IoT) device registry, inaccordance with embodiments of the current disclosure;

FIG. 136 depicts an apparatus for registering meta-devices with anInternet of Things (IoT) device registry, in accordance with anembodiment of the current disclosure;

FIG. 137 depicts device property data types, in accordance with anembodiment of the current disclosure;

FIG. 138 depicts an apparatus for querying an Internet of Things (IoT)device registry, in accordance with an embodiment of the currentdisclosure; and

FIG. 139 is a schematic diagram depicting a supply chain, in accordancewith an embodiment of the current disclosure.

DETAILED DESCRIPTION

The present disclosure will now be described in detail by describingvarious illustrative, non-limiting embodiments thereof with reference tothe accompanying figures and exhibits. The disclosure may be embodied inmany different forms and should not be construed as being limited to theillustrative embodiments set forth herein. Rather, the embodiments areprovided so that this disclosure will be thorough and will fully conveythe concept of the disclosure to those skilled in the art.

Embodiments of the current disclosure are described herein with respectto devices, which includes devices that may form a connected ecosystemof various machines, sensors, and/or other types of devices workingtogether and/or independently with or without human interaction. Devicesmay be modules, e.g., network interface cards, that can be combined withother modules to form other types of devices, e.g., a desktop computerhaving an ethernet network interface card, an 802.11 Wi-Fi networkinterface card, a serial RS232 card, etc. Non-limiting examples ofmodules include network interface cards, processors, memory chips,display controllers/cards, process logic controllers (PLCs), etc. Forexample, as used herein, the term “device” may refer to a module for aproduct, a set of modules for a product, or the entirety of the productthat may have one or more modules incorporated therein. Devices may alsobe Internet of Things (IoT) devices. In embodiments a device may be acollection of chipsets and/or modules contained in a device to perform aspecific function and/or set of functions. In embodiments, a device maybe a collection of associated chipsets and/or modules and/or theiraccompanying identification attributes combined with attributes of acontaining device. Such embodiments may associate embedded componentsabsolutely with respect to a device containing the embedded components.

Traditional approaches of physically securing an enterprise's perimeterdo not meet the needs of an enterprise deploying IoT devices. Forexample, IoT devices used to track products along a supply chain mustoften pass through several entities, each having their own physicalsecurity perimeters where products are allowed to pass between thesecurity perimeters without verifying ownership (and/or securitycredentials) of IoT devices used to monitor the products.

Accordingly, embodiments of the current disclosure provide for aregistry for IoT devices that, in turn, may provide for a deviceidentity authorization process that validates identities of endpoints inan IoT system. Registration of an IoT device may be accomplished via anIoT Universal Identification (IoT UID), as described herein.

In embodiments, a device identity certification process may beconfigured upon enrollment/entry of a device to a platform or othermanagement system, and informs a service provider of the method to beused when checking a device's identity during the registration process.Embodiments of the present disclosure may also provide for systems andmethods for managing a Machine Identity Management platform thatinstills confidence in a device's identity when it interacts with otherdevices, applications, clouds, and/or gateways. As will be explained ingreater detail herein, embodiments of the current disclosure may providefor the verification of an IoT device prior to joining of the IoT deviceto a network, thereby fortifying the perimeter of the network. In otherwords, embodiments of the current disclosure may require (or encourage)an identification and/or verification of an IoT device's identity priorto allowing the IoT device to join a network. In certain aspects,embodiments of the current disclosure provide for a reliable, scalablebackbone for an IoT device registry. In certain aspects, embodiments ofthe current disclosure provide for a subscriber identity module (SIM)for Things, e.g., digital devices, which enables global IoT devicemonitoring via business intelligence (BI) tools. As will also beexplained in greater detail herein, embodiments of the currentdisclosure provide for systems, methods, and apparatuses that improve anentity's confidence in an IoT device's registration, security, andlifecycle management.

Referring now to FIG. 1, a system 1100 for managing network connecteddevices 1112, 1114, 1116, 1118, 1120, 1122, and 1124, in accordance withan embodiment of the current disclosure, includes one or more IoT deviceregistrar/registry servers 1126 and one or more IoT memory devices 1128,which may collectively form an IoT device registry 1129, also referredto herein as “registry”. For example, in embodiments, the one or morememory devices 1128 may form a database that hosts the registry 1129.The one or more servers 1126 and/or the registry 1129 may be operated bya registrar 1130, e.g., an entity that provides registration servicesfor IoT devices. The one or more servers 1126 may each have at least oneprocessor, and may be structured to communicate with the registry 1129.The registry 1129 may include a plurality of records 1131. Inembodiments, the one or more servers 1126 may be included and/orotherwise may form part of the registry 1129.

In embodiments, the IoT device registry 1129 may be accessible via anetwork 1132 to one or more entities 1134, 1136, and/or 1138 that own,possess, operate, and/or otherwise have an interest in the one or moredevices 1112, 1114, 1116, 1118, 1120, 1122, and 1124. Non-limitingexamples of the entities include a manufacturer 1134 of the devices, anend user 1136 of the devices, and a third party 1138. The manufacturer1134 may be an original equipment manufacturer (OEM). The end user 1136may be an enterprise/corporate user and/or a retail user. The thirdparty 1138 may include entities that perform services related to the oneor more devices 1112, 1114, 1116, 1118, 1120, 1122, and 1124, such asmonitoring the one or more devices 1112, 1114, 1116, 1118, 1120, 1122,and 1124 for security vulnerabilities and/or providing software/firmwareupdates. In embodiments, the third party 1138 may be a party who has afinancial interest in the one or more devices 1112, 1114, 1116, 1118,1120, 1122, and 1124, such as a lender of a loan used by an enterprise1136 to purchase the one or more devices 1112, 1114, 1116, 1118, 1120,1122, and 1124 from a manufacturer 1134.

As explained in greater detail herein, the entities 1134, 1136, and/or1138 may send communication data 1140, 1142, 1144 to the IoT deviceregistrar 1130 and/or may receive communication data 1146, 1148, 1150from the IoT device registrar 1130. For example, an enterprise user 1136may send a registration request 1142 for a device 1114 to the registrar1130, which may then register the device 1114 via a record 1152, in theregistry 1129, as being owned by the enterprise 1136. An employee of theenterprise 1136 operating the device 1114 may then wish to interact, viathe device 1114, with another device, e.g., a remote server, operated bya third party 1138. As the device 1114 is registered with the registry1129, the third party 1138 may send a query to the IoT device registrarserver 1126 asking who the registered owner of the device 1114 is. TheIoT device registrar server 1126 may then execute the query 1114 againstthe registry 1129, and may send the result 1150 back to the third party1138, who may then grant or deny the device 1114 access to its devicebased on the result 1150. For example, access may be granted if thedevice 1114 is owned by an approved party, or may be denied if thedevice 1114 is not owned by an approved party. As will be appreciated,other use case examples of the system 1100 are disclosed herein.

Turning to FIG. 2, embodiments of the system 1100 may also include alifecycle management component 2110, an analytics component 2112, amonitoring and security component 2114, and a registration andconfiguration component 2116. The lifecycle management component 2110may include a transfer and ownership subcomponent 2118, a suspend andactivate device subcomponent 2120, and/or a retire device subcomponent2122. The analytics component 2112 may include a device intelligencesubcomponent 2124, a government and risk management subcomponent 2126,and/or a data compliance management subcomponent 2128. The monitor andsecure component 2114 may include a usage and trend analysissubcomponent 2130, a detect unusual behavior subcomponent 2132, and/or aset service alerts subcomponent 2134. The register and configurecomponent 2116 may include a relationships and permission subcomponent2136, a device ID definition subcomponent 2138, and/or a bulk upload andconnect subcomponent 2140. The bulk upload and connect subcomponent 2140may facilitate communication with network connected devices acrossmultiple cloud environments for bulk registrations and/or provisioningone or more devices with respect to the IoT device registry 1129, asdisclosed herein.

As illustrated in FIG. 3, in embodiments of the system 1100, theregistry 1129 may receive events 3110 relating to the one or moredevices 1112, 1114, 1116, 1118, 1120, 1122, and 1124 (FIG. 1), via thenetwork 1132, and/or other information/data 3132 related to the one ormore devices 1112, 1114, 1116, 1118, 1120, 1122, and 1124 from theecosystems 3134, e.g., environments relating to entities 1134, 1136,1138, in which the one or more devices 1112, 1114, 1116, 1118, 1120,1122, and 1124 exist/operate. Events may also come and/or relate tosoftware libraries, software development kits (SDKs), drivers, othermodules, devices, and/or the like. The events 3110 and/or information3132 may be processed by the registry 1129 and/or stored in one or moreapplicable records 1131 (FIG. 1). As explained in greater detail herein,one or more trusted partners/entities 3136 may supply device propertydata 3138, e.g., IDs such as Trusted Platform Module (TPM) keys and/orMedia Access Control (MAC) addresses, that can be mapped by the registry1129 (FIG. 1) to an IoT UID within a record 1131. The system 1100 mayinclude one or more interfaces 3140, 3142, 3144 that allow one or moreentities, e.g., end users 1136, to interact with and/or access theinformation stored within the registry 1129. Embodiments of theinterfaces 3140, 3142, 3144, may provide access to the registry 1129 viasingle panes of glass (SPGs), which may be integrated into a devicemanagement platform, e.g., interface 3144; offered as an applicationwithin an IT/web service platform 3146, e.g., Amazon Web Services,Microsoft Azure, Google Cloud Platform, etc., e.g., interface 3142;and/or hosted on a server independent of an IT/web service platform,e.g., interface 3140. For example, as shown in FIG. 3, enterprise user A3148 may interact with the registry 1129 via an SPG 3140 provided by aserver operated by the registrar 1130, a manufacturer 1134, enterprise A3148 itself, and/or another entity. Enterprise B 3150 may interact withthe registry 1129 via a SPG 3142 offered as an application for purchaseon an existing IT/web service platform 3146. Enterprise C 3152 mayinteract with the registry 1129 via an SPG 3144 integrated into a devicemanagement platform.

FIG. 4 depicts another embodiment of the system 1100 having one or moreinterfaces 4110 and/or 4112 tailored to particular functions that maysupport one or more of the components shown in FIG. 2. In embodiments,the one or more interfaces 4110 and/or 4112 may be SPGs. The one or moreinterfaces 4110 may include dashboards/graphical user interfaces 4110.The dashboards 4110 may provide for a user to manage a network connecteddevice lifecycle 4114, perform analytical analysis 4116, manage risks4118, check and/or ensure compliance 4120 with government and/orindustry regulations and/or standards, and manage security 4122. The oneor more interfaces may also include application programming interfaces(APIs) 4112. The APIs 4112 may provide for device management 4124 and/oranomaly management 4126, as described herein.

Accordingly, and referring to FIG. 5, IoT UIDs 5110 (also shown as 6118in FIG. 6), and the supporting registry 1129, as described herein, mayprovide for a trusted identity 5112 that facilitates trustedinteractions 5114, such as attestations 5116, meta identity 5118engagements, security validations 5120, service verifications 5122, andlifecycle management 5124 for IoT devices. IoT UIDs 5110, and thesupporting registry 1129, may also provide for the detection andhandling of events arising from ecosystems 5126 that may relate to riskmanagement 5128, compliance management 5130, and/or security 5132.

Referring again to FIG. 1, embodiments of the current disclosure mayprovide for an Internet of Things (IoT) device registry 1129, which, inembodiments, may be a backend database 1128 that associates Internet ofThings Universal Identifications (IoT UIDs) with device property data inrecords 1131. Embodiments of the device registry 1129 may also trackand/or provide updates and/or alerts with respect to events relating toregistered IoT devices. As explained in greater detail herein, theregistry 1129 may provide for Seeds of Trust, e.g., the registrar 1130is a trusted source that can be used to determine and/or verify datarelating to an IoT device.

In certain aspects, a manufacturer and/or other entity may be permittedby the registry 1129 to advertise a network connected device as “trustedby [the registry's name]”. In certain aspects, the registry 1129 mayenable an end consumer to receive continued support and/or trackingcapabilities of a network connected device in the event the manufacturer(OEM) goes out of business and/or otherwise ceases support of thenetwork connected device. In certain aspects, the registry 1129 providesmanufacturers (e.g., an OEM, module manufacturer, chipset vendor, IoTedge gateway vendor) of network connected devices with the ability toimprove consumer trust in their products, which, in turn, may preserveand/or improve the manufacturer's reputation. In certain aspects, theregistry 1129 may provide enterprises, e.g., end users of networkconnected devices, with improved trust in supply chains and/or otherindustrial and/or commercial processes. Embodiments of the disclosuremay also provide internet service providers (ISPs), mobile networkoperators (MNOs), and mobile virtual network operators (MVNOs) withimproved confidence that network connected devices operating on theirnetworks are hardened against network attack and/or exploitation.Embodiments of the current disclosure may also provide consumers withimproved confidence in purchasing a network connected device due to thefact that the network connected device can be vetted though theregistry. Embodiments of the current disclosure may also enableenterprises to scale their IoT deployments with the knowledge that theywill have tools to manage and/or mitigate risks, for example, to includethose associated with non-conformance with government and/or industryregulations. Certain aspects of the current disclosure also provide forentities that interact with network connected devices to be agnosticwith respect to the type of network connected devices and/or networks onwhich such devices operate. Embodiments of the current disclosure mayprovide for centralized identity management in combination with robustdevice management, and/or for a highly scalable network connected devicemanagement system based on an API-centric framework that is suited forexponential growth and deployment of IoT devices. Certain aspects of theregistry, as disclosed herein, may also provide for advanced trackingand auditing of network connected devices and/or assets which theymonitor.

Illustrated in FIG. 6 are non-limiting examples of a record 6110, aregistration request 6112, a device status value 6114. and a deviceevent message 6116. Records 6110 may be stored in the registry 1129(FIG. 1), and may include a device IoT UID 6118, device property data6120, and/or other fields 6122. In embodiments, one or more of therecord 6110, the registration request 6112, the device status value6114. and/or the device event message 6116 may correspond to one or moreof the communication data 1140, 1142, 1144, 1146, 1148, and/or 1150(FIG. 1).

Referring to FIG. 7, a connected device may have multiple deviceidentification values, e.g., a MAC address, a user-friendly name, e.g.,“bathroom scale”, and a serial number. For example, an IoT UID mayincorporate and/or represents one or more nested identifications (IDs),such as service, meta, network etc., as disclosed herein. Accordingly,an IoT UID 6118 may be associated with one or more components, e.g., ameta identity component 7110, a service identity component 7112, anetwork identity component 7114, a physical identity component 7116,and/or other types of components, e.g., data types that identify networkconnected device. While FIG. 7 depicts an IoT UID 6118 as being split,it is to be understood that embodiments of the IoT UID may not be split.In embodiments, the components incorporated into an IoT UID and/or usedto generate the IoT UID may not be sequential within an IoT UID. Themeta identity component 7110 may correspond to smart devices, such assmart thermostats, lock systems, lighting systems, etc. The metaidentity component 7110 may also correspond to identifications forindividuals, entities, and/or business processes. Non-limiting examplesof meta identities 7110 include identifications used by consumers e.g.,people, and/or business processes and/or facilities. For example, a metaidentity 7110 may associate a smart thermostat, a lock system, lighting,etc., with one or more processes, such as a distribution center,manufacturing line and/or other components of a supply chain, as well asprovide for tracking and management of network connected devices inresidential environments, e.g., homes. The service identity component7112 may correspond to an international mobile subscriber identity(IMSI), integrated circuit card ID (ICCID), and/or other types ofservice identifiers. The service identity component 7112 may alsocorrespond to identifications for different service profiles.Non-limiting examples of service identities 7112 include internationalmobile subscriber identities (IMSI), integrated circuit card identifiers(ICCID), and types of data used to identify and/or differentiate serviceprofiles. The network identity component 7114 may correspond to a mediaaccess control (MAC) address, an international mobile equipment identity(IMEI), a Bluetooth ID, and/or another type of network-based identifier.Non-limiting examples of network identities 7114 include media accesscontrol (MAC) addresses, international mobile equipment identities(IMEI), Bluetooth IDs, and types of data typically presented to anetwork to identify a device. The physical identity component 7116 maycorrespond to a serial number, a vehicle identification number (VIN),and/or other types of physical object identifiers, which may begenerated at the time of manufacture of the physical object marked bythe physical identifier. Non-limiting examples of physical identities7116 include serial numbers, vehicle identification numbers (VIN), andtypes of data created at the time of manufacture of the device that canbe used to identify the device. While FIG. 7 depicts an IoT UID 6118 of“a66dc016-a2ae-514f-a93c-0597b70ded37” it is to be understood that IoTUIDs 6118 may take other forms. For example, in embodiments, an IoT UID6118 may have a meta identity component 7110 of “Batch358789”, a serviceidentity component 7112 of “313460000345001”, a network identitycomponent 7114 of “351615080091234”, and/or a physical identitycomponent 7116 of “4CE0460DOG”. In embodiments, the meta identitycomponent 7110, service identity component 7112, network identitycomponent 7114, physical identity component 7116, and/or othercomponents may be used as inputs to a process that generates a newvalue. In embodiments, the process may be a hashing algorithm designedto generate unique and/or near unique values based on the meta identitycomponent 7110, service identity component 7112, network identitycomponent 7114, physical identity component 7116, and/or othercomponents. In embodiments, the process may be reversable, e.g., themeta identity component 7110, service identity component 7112, networkidentity component 7114, physical identity component 7116, and/or othercomponents may be (or easily/practically) derivable from the valuegenerated by the process. In embodiments, the process may not be (or noteasily/practically) reversable, e.g., the meta identity component 7110,service identity component 7112, network identity component 7114,physical identity component 7116, and/or other components may not be (ornot easily/practically) derivable from the value generated by theprocess.

IoT UIDs may be embedded, e.g., a copy of the IoT UID is stored in amemory device of the corresponding device, or virtual, e.g., a copy ofthe IoT UID is not stored in a memory device of the correspondingdevice. A record 1152 corresponding to an embedded IoT UID may bereferred to herein as an “embedded record” and/or “an embeddedregistration”. A record 1152 corresponding to a virtual IoT UID may bereferred to herein as a “virtual record” and/or “a virtualregistration”. In embodiments, the property data of a device, e.g.,1112, may form and/or contain a unique signature for the device 1112. Assuch, associating the device data, corresponding to a device, to an IoTUID in a record of the IoT device registry 1129 provides for the abilityto either use the IoT UID to identify the device property data or usethe device property data to identify the IoT UID. In embodiments, therelationship between unique device property data signatures and IoT UIDsmay be one-to-one.

Turning back to FIG. 6, as disclosed herein, device property data 6120stored within a record 6110 may form a unique signature for a particulardevice, e.g., 1118 (FIG. 1). As such, in embodiments, the deviceproperty data 6120 within a record 6110 may be distinguishable from thedevice property data 6120 in other records within the registry 1129(FIG. 1). In other words, the device property data 6120 in a record 6110may constitute a unique signature for the corresponding device that canbe mapped, via the record 6110, to an IoT UID 6118. Non-limitingexamples of device property data 6120 include: meta IDs, e.g., a metaidentity hash; serial numbers; module IDs; module descriptions;manufacturer related data (name, address, phone number, identifier,etc.); manufacture date; batch number; status; firmware version;supported frequency bands; network capabilities (LTE, LTE-A, 5G NR NSA,5G NR SA, etc.); supported communications protocols; last update (oldstatus, new status, date/time stamp, requesting party, reason code);update history; TAC*IMEI; chipset type; chipset manufacturer; centralprocessing unit (CPU); country/regions supported; Universal IntegratedCircuit Card (UICC)/embedded Universal Integrated Circuit Card (eUICC)data, e.g., Integrated Circuit Card ID (ICCID), Embedded IdentityDocument (EID), International Mobile Subscriber Identity (IMSI), MobileStation Integrated Services Digital Network (MISISDN) data, IoT SafeCredentials, etc.; device type/category/class; device label; locationdata, e.g., address, city, zip code, county, country, includinghistorical location data, e.g., a record of past and/or currentlocations of the device; jurisdictional data; encryption keys, e.g.,Trusted Platform Management (TPM) keys, public key infrastructure (PKI)keys, etc.; media access control (MAC) address, Internet Protocol (IP)address; cloud hosting company; current and/or past owner information,e.g., name, address, email, phone number, etc., which may be in the formof an owner identifier value; device specific metrics, e.g.,temperature, location, accelerometer and gyration monitoring data,storage condition data, etc.; and/or other types of data correspondingto a measurable, quantifiable, and/or identifiable property of a device.In embodiments, device property data may include sensor data, e.g.,temperature, pressure, conductivity, amperage, voltage, etc.

Other fields 6122 stored within a record 6110 may include: various typesof metadata associated with a record, e.g., the generation data of therecord, a last modified date of the record, access control dataconcerning the record; pointers to other records in the registry 1129(FIG. 1) and/or other external data sources, e.g., a point to a set orevents associated with the device corresponding to the IoT UID 6118 ofthe record 6110. In embodiments, the other field 6122 may be a list ofone or more events associated with the device corresponding to the IoTUID 6118 of the record 6110. Non-limiting examples of events associatedwith a device include: lifecycle events, e.g., manufacturing events,such as generation/completion of manufacture, incorporation into anotherdevice, repairs, etc.; activation events, such as initial deviceactivation, initial network access, initial assignment to an entityand/or user; retirement/deactivation events, such a removal from anotherdevice, deactivation, etc.; security events, such as date of discoveryof the device being compromised and/or being accessed withoutauthorization; outage events, such as experiencing a network outage,power outage, etc.; ownership events, such as claiming of the device bya new owner, transfer of ownership, licensing of the device, etc.;device property events, such as low battery detected, powered on,powered off, connected to network, disconnected from network, etc.;and/or other types of events that can occur to a device. Additionalnon-limiting examples of events include: module/device registration,e.g., original registration of a module/device; module/device shipment,e.g., registration of a departure of a module/device from manufacturing;module/device integration into another device, e.g., manufacture date ofthe module into a larger device and/or addition of deviceattributes/properties; module/device activation, e.g., initialactivation of device and its associated module(s); device/modulecommunication activation, e.g., addition of communication attributes toa module to assign it to a network/location, which may facilitatebinding of network and device/module identifiers; credential activation,e.g., provision of cloud and/or secondary credentials (such as PKIcertificates, private/public keys, etc.); firmware availabilitynotification, e.g., notification of firmware availability; firmwareupdate, e.g., confirmation of a firmware update; locality/networktransition, e.g., confirmation of a module's/device's locality; chain ofcustody and/or jurisdictional transition, e.g., confirmation of updatesto a module's/device's jurisdiction and/or chain of custody;device/module suspension and/or quarantine, e.g., suspension of amodule/device from operating and/or having network connectivity; and/orpower state/battery notifications, e.g., a notification of a criticalbattery event associated quarantine, and/or other notifications.

A registration request 6112, as disclosed herein, may include deviceproperty data 6124 for one or more devices intended to be registered viathe registry 1129 (FIG. 1), and/or other data 6126. In embodiments, thedevice property data 6124 may be the same as the device property data6120 that gets stored in a record 6110, e.g., where the registrationrequest 6112 is for a single device. In embodiments, the device propertydata 6124 may be a larger set of data as compared to the device propertydata 6120 that gets stored in a record 6110, e.g., where theregistration request 6112 is for multiple devices and the deviceproperty data 6124 is a cumulative set of the properties for the devicesto be registered. In embodiments, the device property data 6124 may be asmaller set of data as compared to the device property data 6120 thatgets stored in a record 6110, e.g., where not all of the data in thedevice property data 6124 is stored in records 6110 in the registry1129. The other data 6126 may include an indication of how many devicesthe registration request 6112 is for and/or what portions of the deviceproperty data 6124 correspond to which device which is to be registered.In embodiments, the other data 6126 may indicate who the requestingentity is, and may include security credentials demonstrating that therequesting entity is authorized to register the devices, and/or otherdata applicable for registering one or more devices with the registry1129.

A device status value 6114, as disclosed herein, may include dataretrieved via querying the registry 1129 (FIG. 1) and/or data sent tothe registry 1129 to update a record 6110. For example, in embodiments,a device status value 6114 may include device property data 6128, an IoTUID 6118, and/or other data 6130. In embodiments, the device propertydata 6128 may be the same as the device property data 6120 in a record6110, e.g., where an entire record is transmitted. In embodiments, thedevice property data 6128 may be less than the device property data 6120in a record 6110, e.g., where only portions of the device property data6120 in a record are transmitted and/or where portions of the deviceproperty data 6120 in a record are redated due to lack of credentialedaccess by an entity querying the registry 1129. Other data 6130 in adevice status value 6114 may include events and/or event messages 6116,metadata regarding the device status value 6114, e.g., the entity towhom the device status value 6114 is being transmitted to, and/or otherdata relevant to the device status value 6114, record 6110, and/or thedevice corresponding to the IOT UID 6118.

Device event messages 6116 may be generated in response to querying theregistry 1129 and/or transmitted to the registry 1129 for associationwith an IoT UID 6118, as disclosed herein. Device event messages 6116may include an IoT UID 6118, device property data 6132, event data 6134,and/or other data 6136. In embodiments, device property data 6132 mayinclude device property data, as disclosed herein, regarding affectedproperties of a device resulting from undergoing/experiencing an eventand/or data relating to the event. Event data 6134 may include datarelating to an event, but may not be associated to an IoT UID 6118within the device event message 6116, e.g., a message indicating that aweather event is occurring in a particular geographic region. Other data6136 may include metadata related to the event message 6116, e.g., atime of the message, to whom/what the message is being transmitted, etc.

As disclosed therein, a device, e.g., 1112, may include one or moremodules, where each module may have its own IoT UID 6118 and/or record6110 (if registered and/or pre-registered, e.g., where a device has arecord but may need to be claimed, as disclosed herein). Accordingly, inembodiments, the device property data 6120 and/or other field/data 6122of a record 6110 corresponding to a device, e.g., a cell phone, mayinclude the IoT UIDs of other devices/modules, e.g., subscriber identitymodules, memory chips, Wi-Fi network interface cards (NICs), etc., thatare related to and/or form part of the device and which can be used toretrieve/identify records in the registry 1129 corresponding to suchother devices/modules.

In embodiments, the registrar 1130 may provide for an applicationprogramming interface (API) and/or web interface that allows a user toregister one or more devices and/or to view and/or enter device events.The user may be a manufacturer 1134, an end user 1136, and/or a thirdparty 1138. Non-limiting examples of such interfaces/APIs are describedand shown in other portions of this disclosure, e.g., FIG. 28.

In embodiments, events may be transmitted to the registry 1129 via adevice manager, connection management platform (CMP), and/or a RemoteAuthentication Dial-In User Service (RADIUS) feed, e.g., an eventstream, or otherwise. In embodiments, events may be retrieved from aHome Location Register (HLR) of a device. Non-limiting examples ofevents from a device management platform include device provisioningevents, device operational events, firmware and/or software updateevents, battery status events, and/or the like. Non-limiting examples ofevents from a CMP include, international mobile subscriber identityrelated events, subscriber identify module (SIM) related events such asactivated and/or suspended. Non-limiting examples of RADIUS feed eventsinclude network related events, e.g., attached and/or detached to andfrom a network, data consumption related events, billing events, e.g.,indication of a bill being ready for processing. Non-limiting examplesof Home Location Register (HLR) events include device on and reachable,device out of coverage, and/or other types of events related to and/ordata stored in a device's HLR.

As disclosed herein, the registry 1129 may respond to queries regardingIoT UIDs, e.g., “is X the true owner of the device associated with IoTUID Y?” via transmitting device property data 6128 and/or a devicestatus value 6128, which may include the device property data 6128, IoTUID 6118, and/or other data 6130, e.g., a listing of events. Theregistry 1129 may provide for restricted access based on permissionlevels, e.g., an original equipment manufacturer (OEM), may be able tosee the patch status of its devices, but not the end users of saiddevices.

In embodiments, the registry 1129 may provide the provisioning of arecord for an IoT UID prior to registration of a corresponding device.For example, a manufacturer 1134 may provide device property data forone or more devices to the registry 1129 that may not have been poweredup for the first time. The registry 1129 may then generate IoT UIDsand/or records for the one or more devices, where each record maycontain an “claimed” field, e.g., other data 6130, indicating that acorresponding device is unclaimed. When a corresponding device issubsequently powered on, it may contact the registry 1129 to finish theregistration process, wherein the registry 1129 updates the “claimed”field to reflect that the corresponding device is active and has beenregistered.

FIG. 8 depicts a schematic diagram of an apparatus 8100 for managingnetwork connected devices 1112, 1114, 1116, 1118, 1120, 1122, 1124 (FIG.1), in accordance with an embodiment of the current disclosure. Theapparatus 8100 may form part of the server 1126 (FIG. 1), e.g., the atleast one processor, and/or any other electronic computing devicedescribed herein. The apparatus 8100 may include a device registrationcircuit 8112 and a device modification circuit 8114. The deviceregistration circuit 8112 may be structured to interpret a deviceregistration request/value 6112 (FIG. 6) that includes device propertydata 6124 (FIG. 6) having an owner identification value. The deviceproperty data 6124 may correspond to at least one of the networkconnected devices 1112, 1114, 1116, 1118, 1120, 1122, 1124 and the owneridentification value may correspond to an owner 1134, 1136, and/or 1138(FIG. 1) of the at least one network connected device 1112, 1114, 1116,1118, 1120, 1122, 1124. The device registration circuit 8112 may befurther structured to store, in a database 1128 (FIG. 1), the deviceproperty data 6120 in a record 6110 (FIG. 6) as corresponding to theowner identification value, and may assign/generate and store an IoT UID6118 in the same record 6110. The device modification circuit 8114 maybe structured to interpret a device status value 61140 (FIG. 6) thatincludes the IoT UID 6118 and device property data 6128. The deviceproperty data 6128 may correspond to an attribute of the at least onenetwork connected device 1112, 1114, 1116, 1118, 1120, 1122, 1124. Thedevice modification circuit 8114 may be further structured to identify,based at least in part on the IoT UID 6118, the record 6110 and, inresponse, modify a field, e.g., 6120 and/or 6122 of the record 6110,based at least in part on the device property data 6128.

In embodiments, the apparatus 8100 may further include an unusualactivity detection circuit 8118 structured to detect unusual activitycorresponding to ownership and/or use of a network connected device1112, 1114, 1116, 1118, 1120, 1122, 1124. The unusual activity detectioncircuit 8118 may detect the unusual activity by analyzing one or more ofthe plurality of records 1131 (FIG. 1). In response to detecting unusualactivity, the unusual activity detection circuit 8118 may generate analert message value 8120. The apparatus 8100 may further include analert provisioning circuit 8122 structured to transmit the alert messagevalue 8120.

Illustrated in FIG. 9 is a method 9100 for managing network connecteddevices 1112, 1114, 1116, 1118, 1120, 1122, 1124 (FIG. 1), in accordancewith an embodiment of the current disclosure. The method 9100 may beperformed by the apparatus 8100 and/or any other computing devicedescribed herein. The method 9100 may include interpreting a deviceregistration value 9112. The device registration value may include adevice property data having an owner identification value. The deviceproperty data may correspond to at least one of the network connecteddevices and the owner identification value may correspond to an owner ofthe at least one network connected device. The method 9100 may furtherinclude storing, in a database, the device property data in a recordcorresponding to the owner identification value 9114 and/or anassigned/generated IoT UID. The method 9100 may further includeinterpreting a device status value that includes the IoT UID and adevice property data 9116. The device property data may correspond to anattribute of the at least one network connected device. The method 9100may further include identifying the record storing the device propertydata 9118 using the IoT UID. The method 9100 may further includemodifying a field of the record based at least in part on the deviceproperty data 9120.

As shown in FIG. 10, the method 9100 may further include verifying thatat least one of the device registration value or the device status valuewas generated by an authorized entity 10110 and 10112. In embodiments,the method 9100 may further include detecting, based at least in part onat least one of the device registration value or the device statusvalue, an unusual event corresponding to the at least one networkconnected device 10114. The method 9100 may further include transmittingan alert message corresponding to the unusual event 10116. The method9100 may further include establishing a Seed of Trust between a registryand an entity that generated at least one of the device registrationvalue or the device status value 10118. In Seed of Trust may be embodiedin the IoT UID, e.g., the IoT UID may represent a collection of knowninformation (device property data) about a device from its time ofmanufacturer (a Greenfield device) or capture (a Brownfield device)through the device's end of life. As disclosed herein, a device's IoTUID may be used to authenticate and/or verify the device during itslifecycle, which may include random attribute challenges in anauthentication process, including multi-factor authentication. As such,an IoT UID may become a trusted identifier that acts as a core kernel oftrust.

Referring now to FIG. 11, an apparatus 11100 for registering devices, inaccordance with an embodiment of the current disclosure, may include anIoT UID processing circuit 11110, a record management circuit 11112,and/or a record provisioning circuit 11114. In embodiments, theapparatus 11100 may form part of the IoT device registrar server 1126,the database 1128, another component of the registrar 1130, and/or anyother computing device described herein. The IoT UID processing circuit11110 may be structured to interpret an IoT UID 6118 (FIG. 6) and deviceproperty data 6120 (FIG. 6). The record management circuit 11112 may bestructured to associate the IoT UID 6118 with the device property data6120 via a record 6110 (FIG. 6). The record provisioning circuit 11114may be structured to transmit the record 6110. As shown in FIG. 12, inembodiments, the apparatus 11100 may further include an updatemanagement circuit 12110 structured to poll an external data source toidentify changes to a device corresponding to the device property data6120 and/or the IoT UID 6118, and update the record 6110 to reflect thechanges.

Illustrated in FIG. 13 is a method 13100 for registering devices, inaccordance with the current disclosure. The method 13100 may beperformed by the apparatus 11100 and/or any other computing devicedescribed herein. The method 13100 may include interpreting an IoT UIDand device property data 13110, and associating the IoT UID with thedevice property data via a record 13112. The method 13100 may furtherinclude transmitting the record 13114.

Turning to FIG. 14, the method 13100 may further include storing therecord in a database 14110. In embodiments, associating the IoT UID withthe device property data via a record 13122 may comprise including theIoT UID and/or the device property data in the record. The method 13100may further include identifying the record in the database based atleast in part on the IoT UID. The method 13100 may further includepolling an external data source to identify changes to a devicecorresponding to the device property data and/or the IoT UID 14116,and/or updating the record to reflect the changes. In embodiments, thedevice property data may indicate that a corresponding device is aGreenfield device. In such embodiments, associating the IoT UID with thedevice property data via the record 13112 may include including anidentifier in the record that indicates the device is a Greenfielddevice 14120. In embodiments, the device property data may indicate thata corresponding device is a Brownfield device. In such embodiments,associating the IoT UID with the device property data via the record13112 may include including an identifier in the record that indicatesthe device is a Brownfield device 14122.

Referring now to FIG. 15, an apparatus 15100 for registering a device,in accordance with an embodiment of the current disclosure, may includean IoT UID processing circuit 15110, a device lookup circuit 15112, anda query provisioning circuit 15114. The IoT UID processing circuit 15110may be structured to interpret an IoT UID 6118. The device lookupcircuit 15112 may be structured to generate a query 15116 that includesthe IoT UID 6118. The query 15116 may be structured to retrieve deviceproperty data 15118. The query provisioning circuit 15114 may bestructured to transmit the query 15116, for example, to an IoT deviceregistrar 1130 (FIG. 1). As shown in FIG. 16, in embodiments, theapparatus 15100 may further include a device property data provisioningcircuit 16110 structured to interpret the device property data 15118retrieved by the query 15116. The apparatus 15100 may further include agatekeeping circuit 16112 structured to grant and/or deny the deviceassociated with the IoT UID 6118 access to another device, e.g., athird-party resource 1138 (FIG. 1) based at least in part on a trustindicator associated with the device associated with the IoT UID 6118.

Illustrated in FIG. 17 is a method 17100 for registering a device, inaccordance with an embodiment of the current disclosure. The method17100 may be performed by the apparatus 15100 (FIG. 15) and/or anycomputing device disclosed herein. The method 17100 includesinterpreting an IoT UID 17110, generating a query that includes the IoTUID 17112. The query may be structured to retrieve device property datacorresponding to the IoT UID. The method 17100 may further includetransmitting the query 17114, for example, to an IoT device registrar1130 (FIG. 1).

As shown in FIG. 18, the method 17100 may further include interpretingthe device property data retrieved by the query 18110. The method 17100may further include displaying a trust indicator associated with thedevice associated with the IoT UID 18112. The method 17110 may furtherinclude denying the device associated with the IoT UID access to anotherdevice, based at least in part on the trust indicator 18114. The method17110 may further include denying the device associated with the IoT UIDaccess to another device, based at least in part on the trust indicator18116.

Referring again to FIG. 1, embodiments of the current disclosure mayprovide for an interface for a user, i.e., a user interface, thatprovides a succinct view of information related to one or moreregistered devices, e.g., devices 1112, 1114, 1116, 1118, 1120, 1122,and 1124, or other information managed by the registrar 1130, e.g., inthe registry 1129, for a user, e.g., an end user 1136, which may be aSingle Pane of Glass (SPG). In certain aspects, any information managedby the IoT registry 1129 that a user wishes to access and has authorityto access is displayed on one display or is all visible at the sametime, which may be, for example, on a single display monitor or across amultiple-monitor display system. Embodiments may determine whichinformation regarding a device (or devices) and/or IoT UID is likely tobe the most relevant to a particular type of user during a particularuse case. Non-limiting examples of user types include one or more endusers 1136 e.g., enterprise, manufacturer 1134, e.g., an originalequipment manufacturer (OEM) and/or factory employees, the IoT deviceregistrar 1130, and/or a third party 1138. Non-limiting examples of usecases include determining the patch states of a fleet of devices,preparing a device for registration, medical device or medicationtracking, and the like. The SPG may provide a graphical user interface(GUI) for the user to interact with, such as to input data, commands,and queries, as well as to display the IoT registry data. The GUI mayprovide access to any of the embodiments of the system 1100 (FIG. 2),for example, the lifecycle management component 2110, the analyticscomponent 2112, the monitoring and security component 2114, and/or theregistration and configuration component 2116.

FIG. 19 depicts a schematic diagram of an example apparatus 19100 fordisplaying Internet of Things (IoT) device registry data, e.g., fornetwork connected devices 1112, 1114, 1116, 1118, 1120, 1122, 1124 (FIG.1), in accordance with an embodiment of the current disclosure. Theapparatus 19100 may form part of the server 1126 (FIG. 1), e.g., the atleast one processor, and/or any other electronic computing devicedescribed herein.

With reference to FIG. 19, the apparatus 19100 is for an Internet ofThings (IoT) device registry display, e.g., an SPG. The apparatus 19100may include a user input processing circuit 19102, an Internet of ThingsUniversal Identification (IoT UID) identification circuit 19104, adevice lookup circuit 19106, a query provisioning circuit 19108, adevice property processing circuit 19110, and a display circuit 19112.The user input processing circuit 19102 may be structured to interpretone or more user input command values 19114. The IoT UID identificationcircuit 19104 may be structured to determine one or more IoT UIDs 19116,based at least in part on the one or more user input command values19114. The device lookup circuit 19106 may be structured to generate aquery 19118 that includes the one or more IoT UIDs 19116, and toretrieve device property data 19120 corresponding to the one or more IoTUIDs 19116. The query provisioning circuit 19108 may be structured totransmit the query 19118 to an IoT device registrar server, e.g., theserver 1126 (FIG. 1). The device property processing circuit 19110 maybe structured to interpret the device property data 19120 generated bythe IoT device registrar server in response to the query 19118. Thedisplay circuit 19112 may be structured to display the device propertydata 19120 with the corresponding one or more IoT UIDs 19116 (also shownas 6118 in FIG. 6).

Certain further aspects of the example system are described asfollowing, any one or more of which may be present in certainembodiments. In the apparatus 19100, the user input command values 19114may include the one or more IoT UIDs 19116. In the apparatus 19100, theuser input command values 19114 may include credentials 19122.Non-limiting examples of credentials 19122 include public keyinfrastructure (PKI) encryption keys, username and password, non-PKIencryption keys, and the like. In the apparatus 19100, the IoT UIDidentification circuit 19104 may be further structured to determine theone or more IoT UIDs 19116 based at least in part on the credentials19122. The apparatus 19100 may further include a filtering circuit 19134structured to filter data in the device property data 19120, based atleast in part on the one or more user input command values 19114. In theapparatus 19100, the filtered data may relate to historical ownership ofa device, e.g., any of devices 1112, 1114, 1116, 1118, 1120, 1122, 1124(FIG. 1), corresponding to one of the IoT UIDs 19116. In the apparatus19100, the device property data 19120 may include a patch status 19224for a device of the corresponding IoT UID. In the apparatus 19100, thedevice property data 19120 may include a security risk analysis value19126 for a device of the corresponding IoT UID. In the apparatus 19100,the device property data 19120 may include a trust level value 19128 fora device of the corresponding IoT UID. The apparatus 19100 may furtherinclude a security alert circuit 19130 structured to generate a securityalert 19132, based at least in part on the security risk analysis value19126 and/or the trust level value 19128. The apparatus 19100 mayfurther include a patching campaign circuit 19136 structured to generateand track a patching campaign 19138 for devices corresponding to one ormore IoT UIDs 19116.

FIG. 20 illustrates a flowchart of an example method 20100 fordisplaying IoT device registry data, e.g., for network connected devices1112, 1114, 1116, 1118, 1120, 1122, 1124 (FIG. 1), in accordance with anembodiment of the current disclosure. The method 20100 may be performedby the apparatus 19100 and/or any other computing device describedherein.

The method 20100 may include interpreting, via a user input processingcircuit, one or more user input command values 20102. The method 20100may further include determining, via an IoT UID identification circuit,one or more IoT UIDs, based at least in part on the one or more userinput command values 20104. The method 20100 may further includegenerating, via a device lookup circuit, a query that includes the oneor more IoT UIDs 20106. The method 20100 may further include retrieving,via the device lookup circuit, device property data corresponding to theone or more IoT UIDs 20108. The method 20100 may further includetransmitting, via a query provisioning circuit, the query to an IoTdevice registrar server 20110. The method 20100 may further includeinterpreting, via a device property processing circuit, the deviceproperty data generated by the IoT UID registrar server in response tothe query 20112. The method 20100 may further include displaying, via adisplay circuit, the device property data with the corresponding one ormore IoT UIDs 20114.

FIG. 21 is another flowchart depicting an embodiment of method 20100 foran IoT device registry display, in accordance with an embodiment of thecurrent disclosure. Certain further aspects of the example method aredescribed as following, any one or more of which may be present incertain embodiments. In the method 20100, the user input command valuesmay include the one or more IoT UIDs. In the method 20100, the userinput command values may include credentials. In the method 20100, thedetermining the one or more IoT UIDs may be based at least in part onthe credentials 21104. With reference to FIG. 21, the method 20100 mayfurther include filtering data in the device property data 21102. Thefiltering may be based at least in part on the one or more user inputcommand values 19114. In the method 20100, the filtered data may relateto historical ownership of a device corresponding to one of the IoTUIDs. In the method 20100, the device property data may include a patchstatus for a device of the corresponding IoT UID. In the method 20100,the device property data may include a security risk analysis value fora device of the corresponding IoT UID. The method 20100 may furtherinclude generating a security alert, based at least in part on thesecurity risk analysis value 21106. In the method 20100, the deviceproperty data may include a trust level value for a device of thecorresponding IoT UID. The method 20100 may further include generating asecurity alert, based at least in part on the trust level value 21108.The method 20100 may further include generating and tracking a patchingcampaign for devices corresponding to one or more IoT UIDs 21110.

FIG. 22 depicts a schematic diagram of an example system 22100 fordisplaying Internet of Things (IoT) device registry data, e.g., fornetwork connected devices 1112, 1114, 1116, 1118, 1120, 1122, 1124 (FIG.1), in accordance with an embodiment of the current disclosure. Thesystem 22100 may form part of the server 1126 (FIG. 1), e.g., the atleast one processor, and/or any other electronic computing devicedescribed herein.

With reference to FIG. 22, the system 22100 is for an IoT deviceregistry display. The system 22100 may include an IoT device registrarserver 22102 and a device management server 22104. The IoT deviceregistrar server 22102 may be structured to provide access to an IoTdevice registry 22106, e.g., the IoT device registry 1129 (FIG. 1). Thedevice management server 22104 may be structured to communicate with theIoT device registrar server 22102, and to provide a graphical userinterface (GUI) 22108 structured to display device property data 22110for one or more devices, e.g., devices 1112, 1114, 1116, 1118, 1120,1122, 1124 (FIG. 1), registered with the IoT device registry 22106. Thedevice property data 22110 may be retrieved by the graphical userinterface 22108 from the IoT device registry via querying the IoT deviceregistrar server 22102, e.g., by a query 22112.

Certain further aspects of the example system are described herein anyone or more of which may be present in certain embodiments. In thesystem 22100, each of the one or more devices may have an IoT UniversalIdentification (UID) 22114 associated with the device. The system 22100may further include a filtering circuit 22116, in communication with thedevice management server, structured to filter data in the deviceproperty data 22110. In the system 22100, the filtered data may relateto historical ownership of a device having an IoT UID associated withthe device. In the system 22100, the device property data 22110 mayinclude a patch status 22118 for a device having an IoT UID associatedwith the device. In the system 22100, the device property data 22110 mayinclude a security risk analysis value 22120 for a device of thecorresponding IoT UID. In the system 22100, the device property data22110 may include a trust level value 22122 for a device of thecorresponding IoT UID. The system 22100 may further include a securityalert circuit 22124 structured to generate a security alert 22126, basedat least in part on the security risk analysis value and/or the trustlevel value. The system 22100 may further include a patching campaigncircuit 22128, in communication with the device management server,structured to generate and track a patching campaign 22130 for devicescorresponding to one or more IoT UIDs 22114. The system 22100 mayfurther include a credential verification circuit 22132, incommunication with the device management server 22104, structured todetermine whether a user of the graphical user interface 22108 isauthorized to access the device property data 22110 for the one or moredevices. If it is determined that the user of the graphical userinterface 22108 is not authorized to access the device property data22110 for the one or more devices, the credential verification circuit22132 is further structured to restrict the display of the deviceproperty data 22110 for one or more devices.

FIG. 23 depicts a schematic diagram of another example apparatus 23100for displaying IoT device registry data, e.g., for network connecteddevices 1112, 1114, 1116, 1118, 1120, 1122, 1124 (FIG. 1), in accordancewith an embodiment of the current disclosure. The apparatus 23100 mayform part of the server 1126 (FIG. 1), e.g., the at least one processor,and/or any other electronic computing device described herein.

With reference to FIG. 23, the apparatus 23100 is for an Internet ofThings (IoT) device registry display. The apparatus 23100 may include atleast one processor 23102 and a memory device 23104. The memory device23104 may store an application 23106 structured to adapt the at leastone processor 23102 to generate a graphical user interface (GUI) 23108structured to receive one or more user input command values 23110,determine, based at least in part on the one or more user input commandvalues 23110, one or more devices registered with an IoT deviceregistry, e.g., the IoT device registry 1129 (FIG. 1), via correspondingIoT UIDs 23112, and display property data 23114 for the one or moredevices.

Certain further aspects of the example apparatus are described asfollowing, any one or more of which may be present in certainembodiments. In the apparatus 23100, the user input command values 23110may include the one or more IoT UIDs 23112. In the apparatus 23100, theuser input command values 23110 may include credentials 23111. In theapparatus 23100, the application 23106 stored in the memory device 23104may be further structured to adapt the at least one processor 23102 todetermine the one or more IoT UIDs 23112 based at least in part on thecredentials 23111. In the apparatus 23100, the application 23106 storedin the memory device 23104 may be further structured to adapt the atleast one processor 23102 to filter data in the device property data23114, based at least in part on the one or more user input commandvalues 23110. In the apparatus 23100, the filtered data may relate tohistorical ownership of a device, e.g., any of devices 1112, 1114, 1116,1118, 1120, 1122, 1124 (FIG. 1), corresponding to one of the IoT UIDs23112. In the apparatus 23100, the device property data 23114 mayinclude a patch status 23116 for a device of the corresponding IoT UID.In the apparatus 23100, the device property data 23114 may include asecurity risk analysis value 23118 for a device of the corresponding IoTUID. In the apparatus 23100, the device property data 23114 may includea trust level value 23120 for a device of the corresponding IoT UID. Inthe apparatus 23100, the application 23106 stored in the memory device23104 may be further structured to adapt the at least one processor23102 to generate a security alert 23122, based at least in part on thesecurity risk analysis value 23118 and/or the trust level value 23120,and provide the security alert 23122 to the graphical user interface23108 to be displayed by the graphical user interface 23108. In theapparatus 23100, the application 23106 stored in the memory device 23104may be further structured to adapt the at least one processor 23102 togenerate and track a patching campaign 23124 for devices correspondingto one or more IoT UIDs 23112 (also shown herein as 6118).

FIG. 24 illustrates a flowchart of an example method 24100 fordisplaying IoT device registry data, e.g., for network connected devices1112, 1114, 1116, 1118, 1120, 1122, 1124 (FIG. 1), in accordance with anembodiment of the current disclosure. The method 24100 may be performedby the apparatus 19100 and/or any other computing device describedherein.

The method 24100 may include generating, via a processor, a graphicaluser interface structured to receive one or more user input commandvalues, and to communicate with an IoT device registrar server 24102,e.g., server 1126 (FIG. 1). The method 24100 may further includereceiving, via the graphical user interface, the one or more user inputcommand values 24104. The method 24100 may further include determining,via the at least one processor, one or more devices registered with anIoT device registry via querying the IoT device registrar server, basedat least in part on the one or more user input command values 24106. Themethod 24100 may further include displaying device property data for theone or more devices received in response to querying the IoT deviceregistrar server 24108.

FIG. 25 is another flowchart depicting a method for an Internet ofThings (IoT) device registry display, in accordance with an embodimentof the current disclosure. FIG. 26 is another flowchart depicting amethod for an IoT device registry display, in accordance with anembodiment of the current disclosure.

Certain further aspects of the example method are described asfollowing, any one or more of which may be present in certainembodiments. In the method 24100, each of the one or more devices mayhave an IoT Universal Identification (UID) associated with the device.With reference to FIG. 25, the method 24100 may further includefiltering data in the device property data 25102. In the method 24100,the filtered data may relate to historical ownership of a device havingan IoT UID associated with the device. In the method 24100, the deviceproperty data may include a patch status for a device having an IoT UIDassociated with the device. In the method 24100, the device propertydata may include a security risk analysis value for a device of thecorresponding IoT UID. The method 24100 may further include generating asecurity alert, based at least in part on the security risk analysisvalue 25104, and displaying the security alert on a same display as thedevice property data 25106. In the method 24100, the device propertydata may include a trust level value for a device of the correspondingIoT UID. The method 24100 may further include generating a securityalert, based at least in part on the trust level value 25108, anddisplaying the security alert on a same display as the device propertydata 25110.

With reference to FIG. 26, the method 24100 may further includegenerating and tracking a patching campaign for devices corresponding toone or more IoT UIDs 26102, and displaying information about thepatching campaign on a same display as the device property data 26104.The method 24100 may further include determining whether a user of thegraphical user interface is authorized to access the device propertydata for the one or more devices 26106, and if it is determined that theuser of the graphical user interface is not authorized to access thedevice property data for the one or more devices, restricting thedisplay of the device property data for one or more devices 26108.

FIG. 27 depicts a schematic diagram of an example apparatus 27100 fordisplaying IoT device registry data, e.g., for network connected devices1112, 1114, 1116, 1118, 1120, 1122, 1124 (FIG. 1), in accordance with anembodiment of the current disclosure. The apparatus 27100 may form partof the server 1126 (FIG. 1), e.g., the at least one processor, and/orany other electronic computing device described herein.

With reference to FIG. 27, the apparatus 27100 is for an Internet ofThings (IoT) device registry display. The apparatus 27100 may include asingle pane of glass (SPG) interface circuit 27102 and a recordmanagement circuit 27104. The SPG interface circuit 27102 is structuredto interpret an IoT UID 27106 received from an SPG. The recordmanagement circuit 27104 is structured to retrieve device property data27108 corresponding to the IoT UID. The SPG interface circuit 27102 isfurther structured to transmit the device property data 27108 to theSPG.

Certain further aspects of the example apparatus are described herein,any one or more of which may be present in certain embodiments. In theapparatus 27100, the IoT UID 27106 and device property data 27108 may beassociated with a device, e.g., any of devices 1112, 1114, 1116, 1118,1120, 1122, 1124 (FIG. 1). The apparatus 27100 may further include afiltering circuit 27110, in communication with the record managementcircuit 27104, structured to filter data in the device property data27108. In the apparatus 27100, the filtered data may relate tohistorical ownership of the device. In the apparatus 27100, the deviceproperty data 27108 may include a patch status 27114 for the device. Inthe apparatus 27100, the device property data 27108 may include asecurity risk analysis value 27116 for a device of the corresponding IoTUID. In the apparatus 27100, the device property data 27108 may includea trust level value 27118 for a device of the corresponding IoT UID. Theapparatus 27100 may include, in communication with the record managementcircuit, a security alert circuit 27120 structured to generate asecurity alert 27122, based at least in part on the security riskanalysis value 27116 and/or the trust level value 27118, and provide thesecurity alert 27122 to the SPG interface circuit 27102 to be displayedby the SPG. The apparatus 27100 may further include a patching campaigncircuit 27124, in communication with the record management circuit,structured to generate and track a patching campaign 27126 for devicescorresponding to one or more IoT UIDs 27106; and provide informationabout the patching campaign 27126 to the SPG interface circuit 27102 tobe displayed by the SPG.

The apparatus 27100 may further include a credential verificationcircuit 27128, in communication with the record management circuit27104, structured to determine whether a user of the SPG is authorizedto access the device property data 27108 corresponding to the IoT UID.The determination may be based on credentials 27130 provided by therecord management circuit 27104. If it is determined that the user ofthe SPG is not authorized to access the device property data 27108corresponding to the IoT UID, the credential verification circuit 27128is further structured to restrict the display of the device propertydata 27108 on the SPG.

FIG. 28 is a diagram of graphical user interfaces, e.g., an SPG, of thesystem of FIG. 1, in accordance with an embodiment of the currentdisclosure.

FIG. 28 depicts non-limiting examples of GUIs that may be used by one ormore users to interact with various components of the system 1100 (FIG.1), e.g., the IoT device registry 1129. GUI 28102 may includeinteractive displays, e.g., a map, and/or other fields for identifyingand/or provisioning network connected devices and/or for ensuring that aregistered network connected device is in compliance with applicablegovernment and/or industry standards and/or regulations. GUI 28104 mayinclude interactive displays and/or other fields for managing risksassociated with registered network connected devices. GUI 28106 mayinclude interactive displays and/or other fields, e.g., SIM address, fortransferring ownership of a network connected device and/or for managingend of life, e.g., decommissioning, of a network connected device. Inembodiments, the GUIs and/or other interfaces described herein, may behosted via a serverless architecture.

In certain aspects, access to an SPG may be based on a subscriptionmodel. In certain aspects, access to an SPG may be provided via anApplication Programming Interface (API) or via a GUI, which may be aweb-based user interface (UI). Embodiments of the SPG may provide for auser to modify a data record in the IoT device registry for one or moredevices. Embodiments of the SPG may provide for the generation andexecution of queries against the IoT device registry. Embodiments of theSPG may provide for a user to validate, e.g., visually, a chain of titlefor a device and/or to inform the IoT device registry of a change inownership for one or more devices. Embodiments may provide for a user toverify a supply chain for a device and/or associated product.Embodiments may provide for a user to see a list of network entry pointsinto a device, which the user can then monitor for security purposes. Incertain aspects, the SPG may restrict and/or filter out displayeddevices based on access rights, e.g., an enterprise user may only beable to view devices that they control and/or own. For example,embodiments may provide for a manufacturer to see a patch version of amodule they made, but not its location and/or current owner. Thefiltering may also comprise a search for a subset of device propertydata, e.g., based on one or more user input command values. In certainaspects, the SPG may be a standalone application, e.g., an Amazon WebServices (AWS) application (“app”), and/or it may be integrated into anexisting platform/system.

Thus, embodiments of an SPG, as disclosed herein, provide for simplifiedaccess to and/or viewing of the status of one or more IoT UIDsassociated with a particular entity, e.g., end user, manufacturer, thirdparty, etc., as compared to traditional systems. For example,embodiments of an SPG may present a view of the data within the IoTdevice registry that is tailored to a particular user of the SPG, e.g.,end user, manufacturer, third part, etc. Thus, an SPG may provide anoverview of all registered devices owned and/or operated by an endenterprise user, and/or provide for a manufacturer to view registereddevices which it made. Embodiments of an SPG may also use filtering, asdescribed herein, to depict only devices and/or corresponding deviceproperty data to which an entity using the SPG is authorized to access.For example, an SPG may allow a manufacturer to view certain propertiesof devices it made but not view ownership information of said devices.Similarly, an SPG may prevent a current owner of a device from viewingprevious ownership data of the device.

Illustrated in FIG. 29 is an architecture 29100 for implementing trustedrelationships between various entities, e.g., 1134, 1136, 1138, and/or1130 (FIG. 1), that manufacture, use, and/or otherwise interact withnetwork connected devices. As will be understood, in embodiments, aninitial trusted relationship, also referred to herein as a “seed oftrust”, may be formed between a manufacturer, e.g., 1134 (FIG. 1) andthe registry 1129. A seed of trust may be a trustable identitycredential, e.g., an IoT UID, embedded within a network connected deviceand/or an association of a device with an IoT UID within the registry1129. In embodiments, the seed of trust may be created at the time ofmanufacturer of a network connected device, e.g., a network connecteddevice may utilize trusted platform module (TPM) technologies. Inembodiments, the registrar 1130 and a manufacturer 1134 (FIG. 1) mayexchange cryptographic keys for one or more network connected devicesover a secure electrical (e.g., secure network connection) and/ortraditional (e.g., secure mail and/or other transport) channel. Once theinitial seed of trust is established, the registrar 1130 can provideverification services to other entities 29110 that may need to interactwith network connected devices registered with the registry 1129. Suchverification services may be provided via one or more applicationprogramming interfaces (APIs) 29112 and/or a real-time query component29114. In certain aspects, embodiments of the disclosure, as disclosedherein, may provide for accurate classification, categorization, andmanagement of the network connected devices, which in turn, may improvethe level of trust between the network connected devices and theentities interacting with them.

Referring again to FIGS. 1 and 2, embodiments of the current disclosuremay provide for the embedding of an IoT UID 6118 (FIG. 6) intoBrownfield devices, e.g., 1112 and 1114. A Brownfield device, asdisclosed herein, may be a device that was previously provisioned and/orin use prior to being associated with and/or assigned an IoT UID 6118. ABrownfield device may be a device that was previously deployed for itsintended purpose, e.g., a device that has left a manufacturer, e.g.,manufacturer 1134 (FIG. 1), and/or has been in operation prior to beingassociated with an IoT UID. As a non-limiting example, an enterpriseuser 1136 (FIG. 1) may purchase a previously used temperature sensorfrom a vendor of used industrial data acquisition devices, wherein thetemperature sensor was never registered with an IoT UID registrar, e.g.,registrar 1130 (FIG. 1), as disclosed herein. The enterprise user 1136may then wish to register the newly purchased used temperature sensorwith the IoT UID registrar, e.g., registrar 1130, as a Brownfield deviceusing the apparatuses and/or method disclosed herein. Brownfield devicesmay also include devices that were previously retired and repurposed,e.g., an old temperature sensor that may have been previously registeredwith an IoT device registrar but was retired/decommissioned,refurbished, and introduced back into use. Apparatuses and/or methodsfor embedding IoT UIDs 6118 into Brownfield devices may form part of theregister and configure component 2116 (FIG. 2), to include the bulkupload & connect 2140, define device ID 2138, and/or configurerelationships and permissions 2136 subcomponents.

Illustrated in FIG. 30 is a process flow diagram depicting two processflows 30100 and 30110 for embedding IoT UIDs into Brownfield devicesinvolving the exchange of data between: a registering party 30112wishing to register Brownfield devices, e.g., an enterprise end user1136 or a manufacturer 1134; an administrator 30114; a device managementplatform 30116; a single pane of glass (SPG) 30118; and an IoT deviceregistrar 1130.

Flow 30100 concerns a scenario in which the registering party 30112wants to register one or more Brownfield devices with embedded IoT UIDsprior to the Brownfield devices entering service within an operationalnetwork, e.g., the registering party 30112 may be an enterprise userprovisioning the Brownfield devices for use in the enterprise user'scorporate network. At 30122, the administrator 30114 may prepare the oneor more Brownfield devices for embedding of an IoT UID. Such preparationmay include updating the firmware and/or software of the one or moreBrownfield devices, installing security credentials, e.g., public keyinfrastructure (PKI) keys and/or certificates, joining to a networkdomain, etc. The administrator 30114 may then collect/gather/generatedevice property data from the prepared one or more Brownfield devices,and then provide/transmit 30124 the gathered device property data to theIoT device registrar 1130. Upon receipt of the device property data, theIoT device registrar 1130 may generate 30126 IoT UIDs for each of theone or more Brownfield devices and associates each IoT UID with portionsof the device property data corresponding to a particular Brownfielddevice. As disclosed herein, such associations may be accomplished via arecord 1152 (FIG. 1), 6110 (FIG. 6) in a registry 1129 (FIG. 1). The IoTdevice registrar 1130 then transmits 30128 the IoT UIDs to the admin30114, who then embeds/loads/installs 30130 each of the IoT UIDs intothe corresponding Brownfield device.

Flow 30110 also concerns a scenario in which the registering party 30112wants to register one or more Brownfield devices with embedded IoT UIDs,where the Brownfield devices are already in service within anoperational network, e.g., the registering party 30112 may be anenterprise user wishing to register Brownfield devices already in use inthe enterprise user's corporate network. Non-limiting examples of suchdevices/scenarios may include: Brownfield devices forming part of anexisting supervisory control and data acquisition (SCADA) network, e.g.,weather and/or power monitors on existing powerline towers; Brownfielddevices deployed to corporate employees, e.g., cell phone, laptops,printers, tablets, etc.; and/or other devices where it would bebeneficial to embed an IoT UID without having to physically bring theBrownfield device to a particular location, e.g., an in-house ITdepartment, for embedding. At 30131, an administrator 30114 may thencollect/gather/generate device property data from one or more Brownfielddevices, which may currently be deployed on a network managed by theadministrator 30114, and provide/transmit 30132 the gathered deviceproperty data to the IoT device registrar 1130. Upon receipt of thedevice property data, the IoT device registrar 1130 may generate 30133IoT UIDs for each of the one or more Brownfield devices and associateseach IoT UID with portions of the device property data corresponding toa particular Brownfield device. As disclosed herein, such associationmay be accomplished via a record 1152 (FIG. 1) 6110 (FIG. 6) in aregistry 1129 (FIG. 1). The IoT device registrar 1130 may then transmit30134 the IoT UIDs to the admin 30114 and/or transmit 30136 the IoT UIDsto a device management platform 30116 that may integrate with a SPG30118. Transmission 30136 of the IoT UIDs to the device managementplatform 30116 may also include a mapping of the IoT UIDs to the one ormore Brownfield devices. The IoT UIDs may then be embedded/installedinto the corresponding Brownfield devices by piggybacking on messages,e.g., base messages, transmitted 30140 to the Brownfield devices, e.g.,via over the air (OTA) updates. In embodiments, the device managementplatform 6136 may insert 30142 the IoT UIDs into software packagesintended to be installed into the Brownfield devices via push and/orpull updates, as represented by the dashed line 30144. Upon receipt ofsuch a software package, the Brownfield devices may install 30146 thepackages (having the piggybacked IoT UID) and transmit 30148confirmation messages, indicating that the IoT UIDs were successfullyinstalled, back to the device management platform 30116, which may inturn relay 30150 the confirmation messages to the IoT device registrar1130, which may then generate 30152 and transmit 30154 trust levelindicators for each of the one or more Brownfield devices, as disclosedherein. Transmission 30154 of the trust level indicators may be to anSPG 30118, device management platform 30116, the administrator 30114,and/or to the Brownfield devices themselves. In embodiments,piggybacking of the IoT UID, as disclosed herein, may way for a devicemanagement interaction with an endpoint device (the device for which theIoT UID corresponds to) to provision the IoT UID. The device managementinteraction may be initiated by one or more of: the device, a regularlyscheduled event by the device or device management platform, and/or oran event initiated by the device management platform to the device. Inembodiments, the IoT UID may piggyback on this event to ensure the IoTUID is provisioned and may include other software, software libraries,drivers, etc. that enable greater functionality and interaction betweenthe device and the IoT device registry, such as enhanced authenticationand security capabilities.

Illustrated in FIG. 31 is a process flow diagram depicting registrationof a Brownfield device with an IoT device registrar 1130, e.g., flow31100, performed in conjunction with a network registration, e.g., flow31110. As will be understood, the functionality and/or control ofBrownfield devices may be divided between: 1) a data plane, e.g.,functionality related to the core intended use of a device such asexecuting a spreadsheet application, collecting and displayingtemperature readings, etc.; and 2) a control plane, e.g., functionalityrelated to regulating network/resource access based on credentials. Inembodiments, flow 31110 may correspond to a setup process for Brownfielddevice data plane functionality, e.g., registration/provisioning with acloud platform 31112 and/or local network, and flow 31100 may correspondto a setup process for Brownfield device registration with the IoTdevice registrar 1130. Accordingly, at 31114, a Brownfield device may beturned on after having been acquired from a previous owner and begin aregistration process with a cloud platform 31112 via transmitting 31116a security certificate to the cloud platform 31112. The cloud platform31112 may then verify 31118 the security certificate and transmit 31120a confirmation message back to the Brownfield device that indicatesregistration with the cloud platform 31112 was successful after whichthe Brownfield device may have access to a variety of resources providedby the cloud platform 31112, e.g., the Brownfield device's data planefunctionality becomes enabled.

The Brownfield device may then proceed to setup its control planefunctionality by transmitting 31122 device registration data to a devicemanagement platform 30116. The device registration data may include thesecurity certificate the Brownfield device used to register with thecloud platform 31112, other device property data, and/or any data theBrownfield device received from the cloud platform 31112 during the dataplane setup process 31110. The device management platform 30116 may thenverify 31124 the device registration data and transmit 31126 an eventmessage, e.g., 6116 (FIG. 6) to the IoT device registrar 1130. The IoTdevice registrar 1130 may then generate IoT UIDs for the Brownfielddevice, as disclosed herein, and/or map 31128 the Brownfield IoT deviceto a preexisting record. For example, in embodiments, the administrator30114 may have used the SPG 30118 to submit device property data for theBrownfield device to the IoT UID device registrar 1130 prior to theexecution of the data plane setup, e.g., flow 31110, to provision arecord for subsequent claiming by the Brownfield device during thecontrol plane setup, e.g., flow 31100. Accordingly, mapping 31128 mayinclude setting a flag and/or other indicator within the recordcorresponding to the Brownfield device indicating that the IoT UID hasbeen claimed by the IoT UID device. The IoT device registrar 1130 mayalso generate and/or set a trust level indictor in the record andtransmit 31130 a confirmation message and/or the trust level indictor tothe device management platform 30116, SPG 30118, registering entity30112, and/or any other interested entity. The device managementplatform 30116 may also relay 31132 the confirmation message to theregistering entity 30112 and/or other interested entity. In embodiments,successful registration of a Brownfield device with an IoT deviceregistrar 1130 may provide for a device management platform 30116 toadjust and/or manipulate the control plane functionality of theBrownfield device, as depicted by dashed line 31134.

Illustrated in FIG. 32 is an apparatus 32100 for provisioning embeddedIoT UIDs in Brownfield devices. The apparatus 32100 may form part of theregistry 1129 (FIG. 1), the IoT device registrar server 1126 (FIG. 1),another component of the registrar 1130, a device management platformassociated with and/or operated by a manufacturer 1134, end user 1136,third party 1138, and/or any computing device described herein. Inembodiments, the apparatus 32100 may include a display circuit 32110, arequestor circuit 32112, a request provisioning circuit 32114, an IoTUID processing circuit 32116, and/or an IoT UID provisioning circuit32118. The display circuit 32110 is structured to generate a graphicaluser interface (GUI), e.g., a SPG, configured to receive one or moreuser input command values 32120 corresponding to device property data6124 (FIG. 6) for one or more Brownfield devices, e.g., 1112, 1114 (FIG.1). The requestor circuit 32112 is structured to generate a registrationrequest 6112 (FIG. 6) that includes the device property data 6124. Therequest provisioning circuit 32114 is structured to transmit theregistration request 6112 to an IoT device registrar server 1126 (FIG.1). The IoT UID processing circuit 32116 is structured to interpret oneor more IoT UIDs 6118 generated by the IoT device registrar server 1126in response to the registration request 6112. The IoT UID provisioningcircuit 32118 is structured to at least one of: transmit the one or moreIoT UIDs 6118, or display the one or more IoT UIDs 6118 on an electronicdisplay.

Moving to FIG. 33, in embodiments, the apparatus 32100 may furtherinclude an embedding verification circuit 33110 structured to interpretembedding confirmation data 33112 that indicates the one or more IoTUIDs 6118 were embedded into the one or more Brownfield devices. Theembedding verification circuit 33110 may be further structured totransmit one or more confirmation messages 33114 indicating the one ormore IoT UIDs were embedded in the one or more Brownfield devices. Theone or more confirmation messages 33114 may include all or some of theembedding confirmation data 33112. In embodiments, the embedding circuit33110 may transmit the confirmation messages 33114 to the displaycircuit 32110 which may be further structured to display the embeddingconfirmation data 33112 in the GUI, e.g., an SPG. In embodiments, theapparatus 32100 may further include a credential circuit 33116structured to interpret a set of credentials 33118. In embodiments, thecredentials 33118 may correspond to a user using the GUI, e.g., an SPG.The credential circuit 33116 may be further structured to transmit theset of credentials 33118 to the IoT device registrar server 1126 (FIG.1). In embodiments, the credentials 33118 may provide authorization toregister the one or more Brownfield devices with an IoT device registry1129 (FIG. 1) associated with the IoT device registrar server 1126 (FIG.1). In embodiments, the IoT UID provisioning circuit 32118 may bestructured to transmit the one or more IoT UIDs 6118 via piggybackingthe one or more IoT UIDs 6118 off of one or more base messages 33120,e.g., transported within and/or with the base messages. The one or morebase messages 33120 may be part of a software and/or firmware updateto/for the one or more Brownfield devices. A non-limiting example ofsuch piggybacking is provided herein with respect to the disclosedprocess flow 30110 in FIG. 30. In embodiments, the one or more basemessages 33120 may be transmitted to the one or more Brownfield devicesat one or more predetermined and/or scheduled times, e.g., planned OTAupdates. In embodiments, the one or more base messages 33120 may betransmitted to the one or more Brownfield devices in response to pollingby the one or more Brownfield devices, e.g., the Brownfield devices maypoll a device management platform to check for available updates.

Referring to FIG. 34, a method 34100 for provisioning embedded IoT UIDsin Brownfield devices, in accordance with embodiments of the currentdisclosure, is shown. The method 34100 may be performed via theapparatus 32100 (FIGS. 32 and 33) and/or any other computing devicedescribed herein. The method 34100 may include identifying one or moreBrownfield devices 34110, and generating device property data, based atleast in part on the one or more Brownfield devices 34112. The method34100 may further include transmitting, to an IoT device registrarserver, a registration request that includes the device property data34114, interpreting one or more IoT UIDs generated in response to thetransmitting of the registration request 34116, and embedding the one ormore IoT UIDs in the one or more Brownfield devices 34118.

Illustrated in FIG. 35 is another apparatus 35100 for provisioningembedded IoT UIDs in Brownfield devices, in accordance with anembodiment of the current disclosure. The apparatus 35100 may form partof the database 1128 (FIG. 1), the registry 1129 (FIG. 1), the IoTdevice registrar server 1126 (FIG. 1), and/or any other computing devicedescribed herein. The apparatus 35100 may include a device registrationcircuit 35110 structured to interpret a registration request 6112, whichmay map device property data 6124 to one or more Brownfield devices. Theapparatus 35100 may further include an IoT UID generation circuit 35112structured to generate an IoT UID 118 for each of the one or moreBrownfield devices based at least in part on the registration request6112. The apparatus 35100 may further include an IoT UID provisioningcircuit 35114 structured to transmit the IoT UIDs 6118.

Shown in FIG. 36 is another method 36100 for provisioning embedded IoTUIDs in Brownfield devices, in accordance with embodiments of thecurrent disclosure. The method 36100 may be performed by the apparatus35100 (FIG. 35) and/or any other computing device disclosed herein. Themethod 36100 may include interpreting, via a device registration requestcircuit, a registration request that maps device property data to one ormore Brownfield devices 36110. The method 36100 may further includegenerating, via an IoT UID generation circuit, based at least in part onthe registration request, an IoT UID for each of the one or moreBrownfield devices 36112. The method 36100 may further includetransmitting, via an IoT UID provisioning circuit, the IoT UIDs 36114.

As illustrated in FIG. 37, the method 36100 may further includeinterpreting one or more confirmation messages indicating that the oneor more IoT UIDs were embedded into the one or more Brownfield devices37110. The method 36100 may further include associating, based at leastin part on the mapping of device property data to the one or moreBrownfield devices, each of the one or more portions of the deviceproperty data with a distinct IoT UID of one or more IoT UIDs in an IoTUID device registry 37112. The method 36100 may further includegenerating a trust level value for each of the one or more Brownfielddevices 37114, and transmitting the trust level value 37116.

Illustrated in FIG. 38 is another method 38100 for provisioning embeddedIoT UIDs in Brownfield devices. The method 38100 includes interpreting,via a request processing circuit, a registration request that includesdevice property data for one or more Brownfield devices 38110. Themethod 38100 further includes generating, via an IoT UID generationcircuit, one or more IoT UIDs, based at least in part on the deviceproperty data 38112. The method 38100 may further include associating,via a record management circuit, each of the one or more IoT UIDs withat least some of the device property data via a record 38114. Inembodiments, the method 38100 may further include transmitting, via anIoT UID provisioning circuit, the one or more IoT UIDs 38116, andinterpreting, via a registration confirmation circuit, one or moreembedding confirmation messages generated in response to transmittingthe IoT UIDs 38118. The one or more embedding confirmation messages mayindicate embedding of the one or more IoT UIDs into the one or moreBrownfield devices.

Referring to FIG. 39, another apparatus 39100 for provisioning IoT UIDsin Brownfield devices is shown. The apparatus 39100 may form part of theIoT registration server 1126 (FIG. 1), the database 1128 (FIG. 1),another portion of the registry 1129, and/or any other computing devicedescribed herein. The apparatus 39100 may include a request processingcircuit 39110, an IoT UID generation circuit 39112, a record managementcircuit 39114, an IoT UID provisioning circuit 39116, and a registrationconfirmation circuit 39118. The request processing circuit 39110 may bestructured to interpret a registration request 6112 that includes deviceproperty data 6124 for one or more Brownfield devices. The IoT UIDgeneration circuit 39112 may be structured to generate one or more IoTUIDs 6118, based at least in part on the device property data. Therecord management circuit 39114 may be structured to associate each ofthe one or more IoT UIDs 6118 with at least some of the device propertydata 6124 via a record 6110. The IoT UID provisioning circuit 39116 maybe structured to transmit the one or more IoT UIDs 6118. Theregistration confirmation circuit 39118 may be structured to interpretone or more embedding confirmation messages 39122 generated in responseto transmitting the IoT UIDs 6118. The one or more embeddingconfirmation messages 39122 may indicate the one or more IoT UIDs 6118were embedded into the one or more Brownfield devices.

An additional non-limiting use case for the methods and/or apparatusesdisclosed herein for provisioning IoT UIDs in Brownfield devicesincludes registering sensors on a resource distribution system, e.g., awater, gas/oil, and/or electricity, distribution system, with an IoT UIDdevice registry without an administrator to physical contact and/orvisit each of the sensors at their operating location. Anothernon-limiting use case for the methods and/or apparatuses disclosedherein for provisioning IoT UIDs in Brownfield devices includesregistering satellites already in orbit with an IoT UID device registry.Another non-limiting use case for the methods and/or apparatusesdisclosed herein for provisioning IoT UIDs in Brownfield devicesincludes registering vehicles in a fleet with an IoT UID deviceregistry. Another non-limiting use case for the methods and/orapparatuses disclosed herein for provisioning IoT UIDs in Brownfielddevices includes registering pallet tracking device already in thefield, e.g., attached to pallets, with an IoT UID device registry.

Referring again to FIGS. 1 and 2, embodiments of the current disclosuremay provide for the embedding of an Internet of Things UniversalIdentifier (IoT UID) 6118 (FIG. 6) into Greenfield devices, e.g., 1116,1118, 1122, and/or 1124. The process of embedding, e.g., installing, IoTUIDs into Greenfield devices may be presale or post-sale. Presaleembedding of an IoT UID 6118 into a Greenfield device may occur prior torelease of the Greenfield device from a manufacturer, for example, anoriginal equipment manufacturer (OEM), for use by end users. Post-saleembedding of an IoT UID 6118 may occur when an end user turns theGreenfield device on after purchasing from the manufacturer. AGreenfield device, as disclosed herein, may be a device that has yet tobe provisioned and/or yet to be used for its intended purpose, e.g., anewly manufactured device and/or a device that has not yet left amanufacturer, e.g., manufacturer 1134 (FIG. 1) (even though the devicemay have been purchased), and/or a device that leaves the manufacturerafter having been associated with an IoT UID. In embodiments, aGreenfield device may be a device obtained by an end user, e.g., 1136,prior to be being provisioned and/or used by another end user, e.g., anew device purchased from a manufacturer and/or a distributor.

As a non-limiting example, an enterprise user 1136 (FIG. 1) may purchasebrand new laptops 1122 and 1124 from a manufacturer 1134 (FIG. 1). Priorto the purchase, the manufacturer 1134 may have provided device propertydata to an IoT device registrar 1130 (FIG. 1) for the new laptops 1122and 1124, and the IoT device registrar 1130 may have registered thelaptops 1122 and 1124 with the registry 1129 (FIG. 1) as disclosedherein. In embodiments, the records 1131 corresponding to the laptops1122 and 1124 may indicate that the manufacturer 1134 is themanufacturer of the laptops 1122 and 1124 and/or the owner of thelaptops 1122 and 1124. Upon executing the sale of the laptops 1122 and1124 to the end user 1136, the manufacturer may transmit an eventmessage 6116 (FIG. 6) to the registrar 1130, which updates the records1131 corresponding to the laptops 1122 and 1124 to reflect that the enduser 1136 is now the owner of these devices but has yet to claim them.Upon taking possession of the laptops 1122 and 1124 after the sale, theuser 1136 may send registration requests 11112 (FIG. 6) to the registrar1130 to register/claim the laptops 1122 and 1124 so that thecorresponding records 1131 reflect that the end user 1136 is now theowner and that the devices have been claimed. The registrar 1130 maythen provide the IoT UIDs 6118 to the end user 1136, who may embed themon memory devices in the laptops 1122 and 1124.

In another non-limiting example, the registrar 1130 may provide the IoTUIDs to the manufacturer 1134 prior to the sale of the laptops 1122 and1124 to the end user, wherein the manufacturer 1134 is the entity whoembeds the IoT UIDs 6118 into the laptops 1122 and 1124 prior to sale ofand/or transfer of possession of the laptops 1122 and/or 1124 to the enduser 1136.

In another non-limiting example, the end user 1136 may be the firstentity to provide the device property data 6124 corresponding to thelaptops 1122 and 1124 to the registrar 1130, after purchasing and takingpossession of the devices, to register them in the name of the end user1136. In other words, in embodiments, a manufacturer need not interactwith the registrar 1130 to embed IoT UIDs 6118 into devices.

In another non-limiting presale example, a manufacturer 1134 may senddevice property data 6132 (FIG. 6) for newly-minted Greenfield devices(and/or modules) to a device management platform, that may then relaythe device property data to an IoT device registrar 1130 (FIG. 1). Theregistrar 1130 may then generate and send the IoT UIDs 6118 to thedevice management platform, which then provides them to the manufacturer1134 for installation into the Greenfield devices before they arereleased to end users. The IoT UIDs 6118 are stored in a database 1128in an IoT device registry 1129 for the IoT device registrar 1130 inassociation with the device property data 6120 so that the IoT UIDs 6118are associated in the registry 1129 with the devices.

As explained in greater detail herein, embodiments of the currentdisclosure may provide for bootstrapping the IoT UID registrationprocess, which may occur presale or post-sale. In a non-limiting exampleof the bootstrap, a manufacturer 1134, e.g., a presale embedding, or anend user, e.g., post-sale embedding, boots up a newly-minted Greenfielddevice, which then proceeds to contact the device management platform toget an IoT UID 6118 from the IoT device registrar 1130. Embodiments ofthe current disclosure may provide for batch registration ofnewly-minted Greenfield devices. Embodiments of the current disclosuremay provide for a device to be “claimed” upon activation by an end userbefore registration can proceed, which may include updating ownershipinformation stored in the registry 1129, updating a chain of titlestored in the registry, etc.

Accordingly, illustrated in FIG. 40 is a process flow diagram depictingtwo process flows 40100 and 40110 for the embedding of IoT UIDs 6118into Greenfield devices involving the exchange of data between: aregistering party, e.g., an enterprise user/device OEM 40122, amanufacturer 40114, a device management platform 40116; a single pane ofglass (SPG) 40118; and an IoT device registrar 1130.

Flow 40100 concerns a scenario in which the device manufacturer 40114 isthe entity embedding the IoT UIDs 6118 into Greenfield devices, which,in embodiments, may be prior to a sale of the Greenfield devices to anEnterprise/Device OEM 40122. Accordingly, at 40120, the manufacturer40114 may generate and transmit device property data of one or moremanufactured Greenfield device to the IoT device registrar 1130. At40120, the IoT device registrar 1130 may then generate an IoT UID 6118for each of the one or more Greenfield devices corresponding to thereceived device property data and transmit the IoT UIDs back to themanufacturer 40114. At 40122, the manufacturer 40114 mayload/install/embed the IoT UIDs received from the registrar 1130 intothe one or more Greenfield devices. In embodiments, the registrar 1130may generate records in the registry for the Greenfield devices when theIoT UIDs 6118 are generated but indicate, in the records, thatGreenfield devices are “unclaimed”, e.g., that they have not beenprovisioned by their eventual first end users. In embodiments, themanufacturer 40114 may fully register the one or more Greenfield devicesafter receiving the IoT UIDs 6118 at 40122, such that the IoT deviceregistrar 1130 records the manufacturer 40114 as the owner of the one ormore Greenfield devices.

Flow 40110 concerns post-sale registration and/or claiming of the one ormore Greenfield devices from flow 40100 upon a bootstrap event, e.g.,turning a device on by a registering party 40112. Accordingly, at 40130the registering party 40112 may turn on the one or more newly purchasedand/or acquired Greenfield devices, which triggers a bootstrapevent/process in each of the one or more Greenfield devices. Inembodiments, the bootstrap process may cause each of the one or moreGreenfield devices to transmit their embedded IoT UID 6118 and/or deviceproperty data to the device management platform 40116. At 40132, thedevice management platform 40116 receives the IoT UIDs 6118 and/ordevice property data and sends a registration request 6112 (FIG. 6) tothe IoT device registrar 1130. In embodiments, the registration request6112 may include the device property data and/or a request for the IoTdevice registrar 1130 to validate the IoT UIDs and correspondingGreenfield devices prior to completing registration of the one or moreGreenfield devices in the name of the registering party 40112. At 40134,the IoT device registrar 1130 may validate that the device property dataand corresponding IoT UIDs in the registration request 6112 based atleast in part on the IoT UID 6118 to device property data associationsin the records created by the IoT device registrar 1130 in flow 40100 at4120. In embodiments, credentials, e.g., cryptographic keys, such as PKIkeys, may be used to validate that a Greenfield device claiming to beassociated with a particular IoT UID at 40134 is the same device made bythe manufacturer 40114. Upon validating the device property data andcorresponding IoT UIDs in the registration request, the IoT deviceregistrar 1130 may update the corresponding records for the one or moreGreenfield devices to reflect that the devices have been claimed and areowned by the registering party 40112. In embodiments, the IoT deviceregistrar 1130 may then generate trust and/or risk scores for each ofthe one or more Greenfield devices, which may be stored in thecorresponding records in the registry and/or transmitted back to thedevice management platform 40116 in a device status value/message 6114that indicates registration of the one or more Greenfield devices iscomplete. In embodiments, the device status value/message 6114 may bereceived by the device management platform at 40136 and/or by the SPG40118 at 40138. At 40140, the device management platform 40116 maytransmit certificates, other credentials, and/or the IoT UIDs 6118 tothe registering entity 40112 and/or load/store/embed the IoT UIDs 6118into the one or more Greenfield devices at 40142. In embodiments, theIoT device registrar 1130 may assign a Greenfield device a higher trustlevel/score (or a lower risk level/score) than a correspondingBrownfield device.

Illustrated in FIG. 41 are three flows 41100, 41110, and 41112 forprovisioning one or more Greenfield devices associated with a cloudplatform 41114, as described herein, for use with the end user 40112. Inembodiments, the one or more Greenfield devices may have previously beenembedded with IoT UIDs 6118, as disclosed herein. Flow 41100 depicts theinstallation of certificates from a device management platform 40116into the one or more Greenfield devices. At 41116, the device managementplatform 40116 may transmit certificates for the one or more Greenfielddevices to the cloud management platform 41114 (received at 41118)and/or the registering entity 40112 (which may be received at 41120 viathe one or more Greenfield devices). The registering entity 40112 maythen claim the certificates from the cloud platform at 41122. Flow 41110depicts the setup of the data plane, as disclosed herein, for the one ormore Greenfield devices. At 41124, the registering entity 40112 maytransmit the certificates and IoT UID 6118 to the cloud platform 41114for verification at 41126 and registration (with the could platform41114). Upon successful registration of the one or more Greenfielddevices, the cloud platform 41114 may transmit a registrationconfirmation message to the registering entity 40112 (received at41128). Flow 41112 depicts the setup of the control plane, as disclosedherein, for the one or more Greenfield devices. At 41130, theregistering entity 40112 transmits its cloud platform registrationinformation/data/credentials to the device management platform 40116which verifies the same at 41132. Upon successful verification, thedevice management platform 40116 may then transmit one or more deviceevent messages 6116 (FIG. 6) to the IoT device registrar 1130 indicatingthat the one or more Greenfield devices have registered with the cloudplatform 41114 and/or device management platform 40116 and/or areclaiming their IoT UIDs 6118 with the registrar 1130. At 41134, theregistrar 1130 may update the corresponding records in the registry 1129to reflect the one or more Greenfield devices are active and/or haveclaimed their IoT UIDs 6118. The registrar 1130 may then generate one ormore trust levels/scores (or risk levels/scores) for the one or moreGreenfield devices and transmit the same, and/or with a successfulclaiming confirmation message, to the device management platform 40116(received at 41136) and/or to the SPG 40118 (received at 41138). Thedevice management platform 40116 may then relay the one or more trustlevels/scores (or risk levels/scores) for the one or more Greenfielddevices to the registering entity 40112 (which may be received by theone or more Greenfield devices at 41140). In embodiments, the conclusionof flow 41112 may enable the data planes of the one or more Greenfielddevices for control via the device management platform 40116, as shownby dashed arrow 41142.

Turning to FIG. 42, a method 42100 for embedding one or more Greenfielddevices with an IoT UID 6118 is shown. The method 42100 may be performedby a manufacturer 1134, e.g., a module manufacturer and/or amanufacturer of a device that includes one or more modules. One or moreprocesses of the method 42100 may be facilitated by an SPG, as disclosedherein. The method 42100 includes manufacturing one or more Greenfielddevices 42110. Manufacturing may include fabricating and/or assemblingone or more components that form a module and/or assembling one or moremodules into a device. The method 42100 further includes generatingdevice property data based at based at least in part on the one or moreGreenfield devices 42112. For example, the device property data of theone or more Greenfield devices may be entered into and/or collected by adevice management platform, as disclosed herein. The method 42100further includes transmitting, to an IoT device registrar server, aregistration request that includes the device property data 42114. Themethod 42100 further includes interpreting one or more IoT UIDsgenerated in response to the transmitting of the registration request42116. The method 42100 further includes embedding the one or more IoTUIDs in the one or more Greenfield devices 42118. In embodiments,embedding the one or more IoT UIDs in the one or more Greenfield devices42118 may occur prior to a sale of the one or more Greenfield devices.In embodiments, embedding the one or more IoT UIDs in the one or moreGreenfield devices 42118 may occur after a sale of the one or moreGreenfield devices.

As shown in FIG. 43, the method 42100 may further include verifying thatthe one or more Greenfield devices are authorized to transmit the deviceproperty data to the IoT device registrar 43110. In embodiments,embedding the one or more IoT UIDs 42118 may include storing the one ormore IoT UIDs in one or more memory locations of the one or moreGreenfield devices 43112. For example, a device management platform maybe used to push/install the IoT UIDs to the Greenfield devices, asdisclosed herein. In embodiments, embedding the one or more IoT UIDs42118 may include installing one or more components into the one or moreGreenfield devices 43114. In embodiments, the one or more components mayinclude the one or more IoT UIDs. For example, such components mayinclude memory chips having IoT UIDs burned and/or programmed into them.In embodiments, the entire method 42100 may be performed prior to a saleof the one or more Greenfield devices.

Illustrated in FIG. 44 is another method 44100 for embedding an IoT UIDinto a Greenfield device. The method 44100 may be performed by amanufacturer 1134, an end user 1136, and/or a third party 1138. Themethod 44100 includes obtaining a Greenfield device 44110, andgenerating, via a device management platform, device property datacorresponding to the Greenfield device 44112. Obtaining a Greenfielddevice 44110 may include receiving, by a first manufacturer, a deviceand/or module from a second manufacturer. Obtaining a Greenfield device44110 may include receiving, by a distributor, a device and/or modulefrom another entity, e.g., a manufacturer and/or another distributor.Obtaining a Greenfield device 44110 may include receiving, by an enduser, a device and/or module from another entity, e.g., a distributorand/or a manufacturer. The method 44100 further includes transmitting,via the device management platform, the device property data to an IoTdevice registrar server 44114. The method 44100 further includesinterpreting, via the device management platform, an IoT UID generatedby the IoT device registrar server in response to the device propertydata 44116. The method 44100 further includes embedding the IoT UID intothe Greenfield device 44118. In embodiments, at least one of generatingthe device property data 44112 or transmitting the device property data44114 forms part of a bootstrapping process, e.g., a bootstrap processinitiated by the Greenfield device.

As shown in FIG. 45, in embodiments, the method 44100 further includesverifying that the Greenfield device is authorized to transmit thedevice property data to the IoT device registrar server 45110. Suchauthorization may include having ownership rights to the Greenfielddevice and the verification process may include transmitting encryptionkeys and/or certificates, as disclosed herein, which may be based atleast in part on a public key infrastructure (PKI). In embodiments, atleast one of generating the device property data 44112 or transmittingthe device property data 44114 is performed via a device managementplatform, as disclosed herein. In embodiments, embedding the IoT UIDinto the Greenfield device 44118 may include storing the IoT UID into amemory location of the Greenfield device 45112. In embodiments,embedding the IoT UID into the Greenfield device 44118 may includeinstalling a component into the Greenfield device 45114. In embodiments,embedding the IoT UID into the Greenfield device 44118 may occur priorto a sale of the Greenfield device. In embodiments, embedding the IoTUID into the Greenfield device 44118 may occur after a sale of theGreenfield device.

Referring to FIG. 46, an apparatus 46100 that initiates a bootstrapprocess for registering with an IoT device registrar 1130 (FIG. 1) isshown. In embodiments, the apparatus 46100 may be incorporated into aGreenfield device, e.g., 1116, 1118, 1122, and/or 1124. The apparatus46100 includes device property data 46110, a memory device 46112, and abootstrapping circuit 46114. The bootstrapping circuit 46114 isstructured to initiate a request 6112, e.g., a registration request, foran IoT UID 6118 from an IoT UID device registrar server 1126 (FIG. 1).The request 6112 may include the device property data 6124 which may bethe same and/or based in part on the device property data 46110. Thebootstrapping circuit 46114 may be further structured to transmit therequest 6112, e.g., to a device management platform for relay to the IoTdevice registrar, or directly to the IoT device registrar. Thebootstrapping circuit 46114 may be further structured to interpret anIoT UID 6118 generated in response to the request 6112, e.g., sent bythe IoT device registrar 1130 and/or the device management platform. Thebootstrapping circuit 46114 may be further structured to store the IoTUID 6118 in the memory device 46112.

As shown in FIG. 47, in embodiments, the apparatus 46100 may furtherinclude a credential circuit 47110 structured to transmit one or morecredentials 47112 that demonstrate authorization to register theapparatus 46100 with an IoT device registrar 1130. In embodiments, theone or more credentials 47112 may be encryption keys, e.g., PKI keys,and/or other types of electronic credentials, as disclosed herein.

FIG. 48 depicts another method 48100 for embedding an IoT UID 6118 in aGreenfield device. The method 48100 may be performed via the apparatus46100 and/or any other computing device disclosed herein. The method48100 includes powering-on a Greenfield device 48110, and initiating abootstrapping process (48114) on the Greenfield device 48112. Thebootstrapping process 48114 may be structured to register the Greenfielddevice with an IoT device registrar 48116, as disclosed herein. Thebootstrapping process 48114 may be structured to embed an IoT UID issuedby the IoT device registrar as part of the registering of the Greenfielddevice 48118. In embodiments, powering-on the Greenfield device 48110may occur prior to a first sale of the Greenfield device. Inembodiments, powering-on the Greenfield device 48110 may be performed bya first owner of the Greenfield device.

Illustrated in FIG. 49 is an apparatus 49100 for registering one or moreGreenfield devices with an IoT device registrar 1130 (FIG. 1). Theapparatus 49100 may form part of the IoT device registrar server 1126,the database 1128 (FIG. 1), and/or any other computing device disclosedherein. The apparatus 49100 may include a device registration circuit49110, an IoT UID generation circuit 49112, and an IoT UID provisioningcircuit 49114. The device registration circuit 49110 is structured tointerpret a registration request 6112 that maps device property data toone or more Greenfield devices, as disclosed herein. The IoT UIDgeneration circuit 49112 is structured to generate, based at least inpart on the registration request 6112, an IoT UID 6118 for each of theone or more Greenfield devices. The IoT UID provisioning circuit 49114is structured to transmit the IoT UID 6118 for each of the one or moreGreenfield devices.

Shown in FIG. 50 is a method 50100 for registering one or moreGreenfield devices with an IoT device registrar. The method 50100 may beperformed by the apparatus 49100 and/or any other computing devicedisclosed herein. The method 50100 includes interpreting a registrationrequest that maps device property data to one or more Greenfield devices50110. The method 50100 further includes generating, based at least inpart on the registration request, an IoT UID for each of the one or moreGreenfield devices 50112. The method further includes transmitting theIoT UIDs for each of the one or more Greenfield devices 50114.

In embodiments, an embedding tool may be used to embed IoT UIDs 6118into devices (Greenfield and/or Brownfield). Non-limiting examples ofembedding tools include USB cables and/or other type of communicationcables, flash memory chips and/or writers, CDs, DVDs, network cards,and/or any type of device capable of loading data to an electronicdevice.

Referring again to FIGS. 1 and 2, embodiments of the current disclosuremay provide for the registration and/or provisioning of Brownfielddevices, e.g., 1112 and 1114 using virtual Internet of Things UniversalIdentifiers (IoT UIDs). A virtual IoT UID occurs where a Brownfield (orGreenfield) device does not include the IoT UID, e.g., a local copy ofthe IoT UID is not stored in the device.

As a non-limiting example, an enterprise user 1136 (FIG. 1) may purchasepreviously used cellular pressure sensors from a vendor for use in anatural gas pipeline, wherein the cellular pressure sensors were neverregistered with an IoT UID registrar, e.g., registrar 1130 (FIG. 1), asdisclosed herein. The enterprise user 1136 may then wish to register thenewly purchased cellular pressure sensors with the IoT UID registrar,e.g., registrar 1130, as Brownfield devices using the apparatuses and/ormethod disclosed herein. The used cellular pressure sensors, however,may not have the capacity and/or ability to store an IoT UID locally intheir memory banks. As such, while the cellular pressure sensors may notbe able to be registered with the IoT device registrar, the cellularpressure sensors may be registered with the IoT device registrar using avirtual IoT UID. The apparatuses and/or methods for registeringBrownfield devices with virtual IoT UIDs 6118, as disclosed herein, mayform part of the register and configure component 21126 (FIG. 2), toinclude the bulk upload & connect 2140, define device ID 2138, and/orconfigure relationships and permissions 2136 subcomponents.

Illustrated in FIG. 51 is a process flow diagram depicting two processflows 51100 and 51110 for embedding IoT UIDs into Brownfield devicesinvolving the exchange of data between: a registering party 51112wishing to register Brownfield devices, e.g., an enterprise end-user1136 or a manufacturer 1134; an administrator 51114; a device managementplatform 51116; a single pane of glass (SPG) 51118; and an IoT deviceregistrar 1130.

Flow 51100 concerns a scenario in which the registering party 51112wants to register one or more Brownfield devices with virtual IoT UIDsprior to the Brownfield devices entering service within an operationalnetwork, e.g., the registering party 51112 may be an enterprise userprovisioning the Brownfield devices for use in the enterprise user'scorporate network. At 51122, the administrator 51114 may prepare the oneor more Brownfield devices for registration with the IoT deviceregistrar 1130. Such preparation may include updating the firmwareand/or software of the one or more Brownfield devices, installingsecurity credentials, e.g., public key infrastructure (PKI) keys and/orcertificates, joining to a network domain, etc. The administrator 51114may then collect/gather/generate device property data from the preparedone or more Brownfield devices, and then provide/transmit 51124 thegathered device property data to the IoT device registrar 1130. Uponreceipt of the device property data, the IoT device registrar 1130 maygenerate 51126 IoT UIDs for each of the one or more Brownfield devicesand associates each IoT UID with portions of the device property datacorresponding to a particular Brownfield device. As disclosed herein,such associations may be accomplished via a record 1152 (FIG. 1), 6110(FIG. 6) in a registry 1129 (FIG. 1). The IoT device registrar 1130 mayalso generate 51126 trust and/or risk level/indicator/score for each ofthe Brownfield devices being registered and store/update 51128 thecorresponding records to reflect the trust and/or risklevel/indicator/score. The IoT device registrar 1130 may then transmitSO51128 the generated IoT UIDs, trust and/or risklevels/indicators/scores, and/or device property data for the Brownfielddevices to the SPG 51118.

Flow 51110 concerns a scenario where a bootstrap event/process isinitiated by the registering party 51112 on a Brownfield device andregisters with the IoT device registrar 1130. At 51130, the registeringparty 51112 initiates the bootstrap event on the Brownfield device whichtransmits device property data 6124 to the device management platform51116. The device management platform 51116 may then relay 51132 thedevice property data 6124 to the IoT device registrar 1130. At 51134,the IoT device registrar 1130 may validate that device property data,e.g., check that the registering party 51112 is authorized to registerthe Brownfield device using encryption certificates, as disclosedherein; and/or verify that the device property data matches any deviceproperty data for the Brownfield device previously submitted to the IoTdevice registrar 1130 by the administrator, such as in flow 51100. At51136, the IoT device registrar 1130 may transmit a registrationconfirmation message to the device management platform 51116 with mayinclude the IoT UID and/or a generated trust and/or riskindicator/level/score for the Brownfield device. At 51138, the IoTdevice registrar 1130 may transmit the IoT UID, device property data,and/or a trust and/or risk indicator/level/score for the Brownfielddevice to the SPG 51118. In embodiments, at 51120, the device managementplatform 51116 may transmit credentials to the Brownfield device.

Illustrated in FIG. 52 is a process flow diagram depicting registrationof a Brownfield device with an IoT device registrar 1130, e.g., flow52100, using a virtual IoT UID 6118 performed in conjunction with anetwork registration, e.g., flow 52110. As disclosed herein, thefunctionality and/or control of Brownfield devices may be dividedbetween a data plane and a control plane. In embodiments, flow 52100 maycorrespond to a setup process for Brownfield device data planefunctionality, e.g., registration/provisioning with a cloud platform52112 and/or local network, and flow 52110 may correspond to a setupprocess for Brownfield device registration with the IoT device registrar1130. Accordingly, at 52114, a Brownfield device may be turned on afterhaving been acquired from a previous owner and begin a registrationprocess with a cloud platform 52112 via transmitting 52116 a securitycertificate to the cloud platform 52112. The cloud platform 52112 maythen verify 52118 the security certificate and transmit 52120 aconfirmation message back to the Brownfield device that indicatesregistration with the cloud platform 52112 was successful after whichthe Brownfield device may have access to a variety of resources providedby the cloud platform 52112, e.g., the Brownfield device's data planefunctionality becomes enabled.

The Brownfield device may then proceed to set up its control planefunctionality by transmitting 52122 device registration data to a devicemanagement platform 51116. The device registration data may include thesecurity certificate the Brownfield device used to register with thecloud platform 52112, other device property data, and/or any data theBrownfield device received from the cloud platform 52112 during the dataplane setup process 52100. The device management platform 51116 may thenverify 52124 the device registration data and transmit 52126 an eventmessage, e.g., 6116 (FIG. 6) to the IoT device registrar 1130. Inembodiments, the device management platform 51116 may transmit 52125 aconfirmation message to the Brownfield device. The IoT device registrar1130 may then generate IoT UIDs for the Brownfield device, as disclosedherein, and/or map 52128 the Brownfield IoT device to a preexistingrecord. For example, in embodiments, the administrator 51114 (FIG. 51)may have used the SPG 51118 to submit device property data for theBrownfield device to the IoT UID device registrar 1130 prior to theexecution of the data plane setup, e.g., flow 52100, to provision arecord for subsequent claiming by the Brownfield device during thecontrol plane setup, e.g., flow 52110. Accordingly, mapping 52128 mayinclude setting a flag and/or other indicator within the recordcorresponding to the Brownfield device indicating that the IoT UID hasbeen claimed by the IoT UID device. The IoT device registrar 1130 mayalso generate and/or set a trust level indictor in the record andtransmit 52130 a confirmation message and/or the trust level indictor tothe device management platform 51116, SPG 51118, registering entity51112, and/or any other interested entity. The IoT device registrar 1130may also transmit 52132 the confirmation message to the SPG 51118. Inembodiments, successful registration of a Brownfield device with an IoTdevice registrar 1130 using a virtual IoT UID 6118 may provide for adevice management platform 51116 to adjust and/or manipulate the controlplane functionality of the Brownfield device, as depicted by dashed line52134.

Shown in FIG. 53 is an apparatus 53100 for registering one or moreBrownfield devices via a virtual Internet of Things Universal Identifier(IoT UID). In embodiments, the apparatus 53100 may form part of a devicemanagement platform and/or SPG, as disclosed herein. In embodiments, theapparatus 53100 may form part of an IoT device registrar server 1126, acomputing system operated and/or used by an end-user 1136 and/or a thirdparty 1138, and/or any other computing device described herein. Theapparatus 53100 includes a display circuit 53110, a requestor circuit53112, a request provisioning circuit 53114, an IoT UID processingcircuit 53116, and an IoT UID provisioning circuit 53118. The displaycircuit 53110 may be structured to generate a graphical user interface,e.g., a SPG (as disclosed herein), configured to receive one or moreuser input command values 53119 corresponding to device property data6124 from one or more Brownfield devices, e.g., 1112, 1114, 1120, (FIG.1). The requestor circuit 53112 may be structured to generate a virtualregistration request 53120 that includes the device property data 6124.A virtual registration request may include a field and/or otherindication that the registration is to be via a virtual IoT UID, asopposed to an embedded IoT UID, as disclosed herein. The requestprovisioning circuit 53114 may be structured to transmit the virtualregistration request 53120 to an IoT device registrar server 1126 (FIG.1). The IoT UID processing circuit 53116 may be structured to interpretone or more virtual IoT UIDs 6118 generated by the IoT device registrarserver 1126 in response to the virtual registration request 53120. TheIoT UID provisioning circuit 53118 may be structured to transmit the oneor more virtual IoT UIDs 6118 and/or display the one or more virtual IoTUIDs 6118 on an electronic display, e.g., a SPG as disclosed herein.

As shown in FIG. 54, embodiments of the apparatus 53100 may include averification circuit 54110 structured to verify that an entityrequesting registration of the one or more Brownfield devices isauthorized to do so. Such verification may involve inspecting and/orverifying one or more cryptographic keys and/or certificates, which maybe based on a public key infrastructure (PKI).

Illustrated in FIG. 55 is a method 55100 for registering one or moreBrownfield devices via a virtual Internet of Things Universal Identifier(IoT UID). The method 55100 may be performed via the apparatus 53100and/or any other computing device described herein. The method 55100includes identifying one or more Brownfield devices 55110; generatingdevice property data based at least in part on the one or moreBrownfield devices 55112, and transmitting, to an IoT device registrar,a registration request (which may be a virtual registration request)that includes the device property data 55114. The method 55100 mayfurther include interpreting one or more IoT UIDs generated in responseto the transmission of the registration request 55116.

As shown in FIG. 56, the method 55100 may further include verifying thatan entity requesting registration of the one or more Brownfield devicesis authorized to do so 56110. The method 55100 may further includeinterpreting, via a device management platform, a message from the IoTdevice registrar server that provides confirmation that the one or moreBrownfield devices were successfully registered with an IoT deviceregistry corresponding to the IoT device registrar server 56112.

Illustrated in FIG. 57 is another apparatus 57100 for registering one ormore Brownfield devices via a virtual Internet of Things UniversalIdentifier (IoT UID). In embodiments, the apparatus 57100 may form partof a device management platform and/or SPG, as disclosed herein. Inembodiments, the apparatus 57100 may form part of an IoT deviceregistrar server 1126, a computing system operated and/or used by anend-user 1136 and/or a third party 1138, and/or any other computingdevice described herein. The apparatus 57100 includes a deviceregistration request circuit 57110, an IoT UID generation circuit 57112,a record management circuit 57114, and an IoT UID provisioning circuit57116. The device registration request circuit 57110 may be structuredto interpret a virtual registration request 6112 that maps deviceproperty data 6124 to the one or more Brownfield devices. The IoT UIDgeneration circuit 57112 may be structured to generate, based at leastin part on the virtual registration request 6112, an IoT UID 6118 foreach of the one or more Brownfield devices. The record managementcircuit 57114 may be structured to generate a record 6110 (FIG. 6) foreach of the IoT UIDs 6118. The record management circuit 571114 may befurther structured to associate each of the IoT UIDs 6118 with portionsof the device property data 6124 corresponding to a distinct one of theone or more Brownfield devices. The IoT UID provisioning circuit 57116may be structured to transmit the IoT UIDs.

As shown in FIG. 58, the apparatus 57100 may further include averification circuit 58110 structured to verify that an entityrequesting registration of the one or more Brownfield devices isauthorized to do so, in accordance with the methods described herein.

Illustrated in FIG. 59 is another method 59100 for registering one ormore Brownfield devices via a virtual Internet of Things UniversalIdentifier (IoT UID). The method 59100 includes interpreting, via adevice registration request circuit, a virtual registration request thatmaps device property data to one or more Brownfield devices 59110. Themethod 59100 further includes generating, via an IoT UID generationcircuit, based at least in part on the virtual registration request, anIoT UID for each of the one or more Brownfield devices 59112. The method59100 further includes generating, via a record management circuit, arecord for each of the IoT UIDs 59114. The method 59100 further includesassociating, via the record management circuit, each of the IoT UIDswith portions of the device property data corresponding to a distinctone of the one or more Brownfield devices 59116. The method 59100further includes transmitting, via an IoT UID provisioning circuit, eachof the IoT UIDs 59118.

As shown in FIG. 60, in embodiments, the method 59100 may furtherinclude verifying that an entity requesting registration of the one ormore brownfield devices is authorized to do so 600110.

An additional non-limiting use case for the methods and/or apparatusesdisclosed herein for provisioning IoT UIDs in Brownfield devicesincludes registering sensors on a resource distribution system, e.g., awater, gas/oil, and/or electricity, distribution system, with an IoT UIDdevice registry without an administrator to physical contact and/orvisit each of the sensors at their operating location. Anothernon-limiting use case for the methods and/or apparatuses disclosedherein for provisioning IoT UIDs in Brownfield devices includesregistering satellites already in orbit with an IoT UID device registry.Another non-limiting use case for the methods and/or apparatusesdisclosed herein for provisioning IoT UIDs in Brownfield devicesincludes registering vehicles in a fleet with an IoT UID deviceregistry. Another non-limiting use case for the methods and/orapparatuses disclosed herein for provisioning IoT UIDs in Brownfielddevices includes registering pallet tracking devices already in thefield, e.g., attached to pallets, with an IoT UID device registry.

Referring again to FIGS. 1 and 2, embodiments of the current disclosuremay provide for the registration and/or provisioning Greenfield devicesusing virtual Internet of Things Universal Identifiers (IoT UIDs). Avirtual IoT UID occurs where a Greenfield (or Brownfield) device doesnot include the IoT UID, e.g., a local copy of the IoT UID is not storedin the device. A virtual IoT UID may be converted to an embedded IoT UIDby embedding the IoT UID in the device, e.g., storing the IoT UID in amemory location on the device. An embedded IoT UID may be converted to avirtual IoT UID by removing the IoT UID from the device.

Illustrated in FIG. 61 is a process flow diagram depicting two processflows 61104 and 61114 for associating IoT UIDs with Greenfield devicesinvolving the exchange of data between: a registering party 61100wishing to register Greenfield devices, a device management platform61116, a single pane of glass (SPG) 61115, an IoT device registrar 1130.

Flow 61104 concerns a scenario in which the registering party 61100,e.g. a factory/original equipment manufacturer (OEM) 1134, wants toregister one or more pre-sale Greenfield devices with virtual IoT UIDs.Starting with a Greenfield device ready for credentials 61120, at 61122device property data 6124 (FIG. 6) for multiple modules may be sent inbulk to the IoT device registrar 1130. At 61118 the IoT device registrar1130 generates IoT UIDs for each of the multiple modules. The module isnow bootstrap ready 61124.

Flow 61114 concerns a scenario in which the registering party 61100,possibly an enterprise 1136, initiates the bootstrap event 61128 on aGreenfield device which transmits the device property data 6124 to thedevice management platform 61116. The device management platform 61116may then relay 61130 the device property data 6124 to the IoT deviceregistrar 1130. At 61132, the IoT device registrar 1130 may validate themodule information/device property data 6120 and associate the deviceproperty data 6124 and an enterprise name with a virtual IoT UID. At61134, the IoT device registrar 1130 provides validation of success orfailure to the device management platform 61116. At 61138, assigns anappropriate trust level to the module. At 61140, the IoT deviceregistrar 1130 provide the IoT UID, assigned trust level and deviceproperty data 6124 to the SPG 61115. At 61142, to the device managementplatform 61116 may transmit the certificates, other credentials, and/orthe IoT UIDs to the registering party 61100. At 61144, the registeringparty 61100 may load/store/embed the IoT UIDs into the one or moreGreenfield devices, resulting in a Greenfield device/module ready foroperations 61148.

Illustrated in FIG. 62, are three flows 62100, 62102, and 62104 forprovisioning one or more Greenfield devices associated with a cloudplatform 62110, as described herein, for use by an end user. Inembodiments, the one or more Greenfield devices may have previously beenassigned virtual IoT UIDs, as disclosed herein.

At flow 62100, an enterprise administrator 62108 claims ownership of anenterprise Greenfield device 62113. At 62114, the device managementpartner platform 62116 sends certificates for the enterprise devices62113 acquired by the enterprise to the cloud platform 62110. At 62118,the device management partner platform 62116 sends certificates for theenterprise devices 62113 to the enterprise administrator 62108. At62120, the administrator 62108 then claims the certificates on the cloudplatform 62110 into an enterprise account. At 62122, an enterprisedevice 62113 is turned on.

At flow 62102, a data plane between the enterprise Greenfield device62113 and the cloud platform 62110 is established. At 62124, theenterprise Greenfield device 62113 sends a device registration to thecloud platform 62110. At 62128, the cloud platform 62110 verifies thecertificate provided by the enterprise Greenfield device 62113. At62130, the cloud platform 62110 sends a confirmation of registrationsuccess to the enterprise Greenfield device 62113 which, in embodiments,may establish, the data plane 62132 between the enterprise Greenfielddevice 62113 and the cloud platform 62110.

At flow 62104, a control plane between the enterprise Greenfield deviceand the device management partner platform 62112 is setup. At 62134, theenterprise Greenfield device sends device registration information tothe device management partner platform 62112. At 62138, the devicemanagement partner platform 62116 verifies the credentials. At 62140,the device management partner platform 62112 relays the event deviceprovisioning information to the IoT device registrar 1130. At 62142, theIOT device registrar 1130 maps the provided provisioning informationonto an IoT UID, updates the registry and provides a trust level. At62144, the IOT device registrar 1130 relays confirmation of success tothe device management partner platform 62116. At 62148, the IOT deviceregistrar 1130 relays confirmation of success and the device trust levelto the SPG. At 62150, the device management partner platform 62116relays confirmation of registration success to the enterprise Greenfielddevice which mat signal that control plane 62152 between the enterpriseGreenfield device and the device management partner platform 62116 isenabled/active. The device may then be provisioned 62154 and managed62158 and ready to be used 62160.

Illustrated in FIG. 63, are two flows 63120, 63122 for handlingnotifications during operations on operational enterprise Greenfielddevices 62113. At 63124, notifications and events are exchanged betweenthe ecosystem 63100 and the IoT device registrar 1130, as disclosedherein. At 63128, notifications and events are exchanged between thenetworks 63102 and the IoT device registrar 1130.

At flow 63120, firmware on an enterprise Greenfield device 62113 isupdated. At 63124, the ecosystem 63100 exchanges notifications andevents with the IoT device registrar 1130. At 63126, the networks 63102exchange notifications and events with the IoT device registrar 1130. At63128 the ecosystem 63100 provides the firmware update data, e.g., themodule, chipset, device types, and the like, to the IoT device registrar1130. At 63130, the IoT device registrar 1130 links the firmware updatedata to a specific IoT UID. At 63132, the IoT device registrar 1130provides the firmware update, e.g., IoT UID, module, device and thelike, to the device management partner platform 62116. At 63134, thedevice management partner platform 62116 may send a trigger signal tothe enterprise device 62113 causing the enterprise device 62113 toupdate the firmware. At 63140, the enterprise device 62113 may thenupdate the firmware. At 63142, the enterprise device 62113 may relay astatus value, reflective of the success of firmware update, to thedevice management partner platform 62116. At 63144, the devicemanagement partner platform 62116 may relay a status value, reflectiveof the success of the firmware update, to the IoT device registrar 1130.At 63148 the IoT device registrar 1130 may update the device's IoT UID,trust level or the like.

At flow 63122, information regarding a security event is propagatedthrough the system. At 63150, a device attribute change is communicatedfrom the ecosystem 63100 to the IoT device registrar 1130. At 63152, theIoT device registrar 1130 links the device attribute change with thedevice's virtual IoT UID. At 63154, the IoT device registrar 1130 mayprovide a security signal, data on the event, information on IoT device,and the like, to the device management partner platform 62116. At 63158,the device management partner platform 62116 may send informationregarding the event and IoT UID to the SPG. At 63160, the devicemanagement partner platform 62116 may trigger a security action, e.g.,patching. At 63162, the IoT device registrar 1130 may send event data tothe SPG 61115. In embodiments, at 63164, the IoT device registrar 1130may provide a security signal event, e.g., the IoT UID, event details,and the like, to the cloud platform 62110. At 63168, the cloud platform62110 may trigger a security action.

Illustrated in FIG. 64 is a method 64100 for registering one or moreGreenfield devices via a virtual Internet of Things Universal Identifier(IoT UID), in accordance with an embodiment of the current disclosure.The method 64100 may include manufacturing at least a portion of aGreenfield device (step 64102). The method 64100 further includes, via adevice management platform, generating device property data 64118corresponding to the Greenfield device (step 64104) and generating avirtual registration request that includes the device property data64118 (step 64108). The method 64100 further includes, via the devicemanagement platform, transmitting the virtual registration request to anIoT device registrar server (step 64110) and interpreting an IoT UIDgenerated by the IoT Device registrar server in response to the deviceproperty data 64118 (step 64112). In embodiments, the method may furtherinclude verifying that an entity requesting registration of theGreenfield device is authorized to do so (step 64114) usingcryptographic keys or a Public Key Infrastructure (PKI) 64120.

Illustrated in FIG. 65 is a method 65100 for registering one or moreGreenfield devices via a virtual Internet of Things Universal Identifier(IoT UID), in accordance with an embodiment of the current disclosure.The method 65100 may include powering-on a Greenfield device (step65102) and initiating a bootstrapping process on the Greenfield deviceto virtually register the device with an IoT device registrar 1130 (step65104). The method 65100 may further include releasing the Greenfielddevice for use by an end user (step 65106). The process start 65100 mayoccur prior to sale, e.g. where the registering party 61100 is afactory/original equipment manufacturer (OEM) 1134. The process start65100 may occur after the Greenfield device has been sold, e.g. wherethe registering party 61100 is an enterprise 1136.

Illustrated in FIG. 66, is a method 66100 for registering one or moreGreenfield devices via a virtual Internet of Things Universal Identifier(IoT UID), in accordance with an embodiment of the current disclosure.The method 66100 may include interpreting, via a device registrationrequest circuit, a virtual registration request (step 66102) for one ormore Greenfield devices. The virtual registration request 66118 mayinclude device property data 66102. The method 66100 may includegenerating, via an IoT UID generation circuit, an IoT UID for each ofthe Greenfield devices for which a virtual registration request wasreceived (step 66104). The method 66100 further includes, via a recordmanagement circuit, generating an IoT UID record(s) 66120 for each ofthe IoT UIDs (step 66108) and associating each of the IoT UIDS withportions of the device property data 66102 corresponding to a distinctGreenfield device (step 66110). The method 66100 may further includetransmitting, via an IoT UID provisioning circuit, the IoT UIDs to adevice management platform (step 66112).

Illustrated in FIG. 67, a system 67100, may include manufacturingcomponents 67102 that generate at least a portion of a Greenfield device67104. The system 67100 may further include a device management platform67110. The device management platform 67110 may include a deviceregistration request circuit 67120 which interprets a virtualregistration request 67112, which may include property device data67108. The system 67100 may further include an IoT device registrar67118. The IoT device registrar 67118 may include a IoT UID generationcircuit 67122 for generating an IoT UID 67114 and a record managementcircuit 67122 for generating IoT UID(s) 67128 including an IoT UID67114.

Illustrated in FIG. 68, an apparatus 68100 for registering one or moreGreenfield device via a virtual Internet of Things Universal Identifier(IoT UID). The apparatus 68100 may include device property data 67108and a bootstrapping circuit 68102 structured to initiate a virtualregistration request 67112 that includes the device property data 67108.

In a non-limiting example of the bootstrap registration process, amanufacturer, e.g., pre-sale, or an end user, e.g., post-sale, boots upa newly-minted Greenfield device which then proceeds to contact thedevice management platform, which may then request (of the IoT deviceregistrar) to register the Greenfield device via a virtual IoT UID.Embodiments may provide for batch registration of newly-mintedGreenfield devices. Embodiment may provide for a device to be “claimed”upon activation by an end user before registration can proceed, whichmay include updating ownership information stored in the registry,updating a chain of title stored in the registry, etc. Embodiments mayprovide for verifying that the entity requesting registration of theGreenfield device authorized to do so. Verification authorization of theentity requesting registration may include the use of cryptographickeys, a Public Key Infrastructure (PKI), or the like.

Referring again to FIG. 1, embodiments of the current disclosure mayprovide for the lifecycle management for Internet of Things (IoT)devices, e.g., devices 1112, 1114, 1116, 1118, 1120, 1122, and 1124,managed by the registrar 1130, e.g., in the registry 1129.

Non-limiting examples of user types include one or more end users 1136,e.g., enterprise, manufacturer 1134, e.g., an original equipmentmanufacturer (OEM) and/or factory employees, the IoT device registrar1130, and/or a third party 1138. Information may be provided, e.g.,displayed, by a Single Pane of Glass (SPG), which may provide agraphical user interface (GUI), e.g., any of GUIs 22108 (FIG. 22), 23108(FIG. 23), 28102 (FIG. 28), 28104 (FIG. 28), or 28106 (FIG. 28), for theuser to interact with, such as to input data, commands, and queries, aswell as to display the IoT registry data. The GUI may provide access toany of the embodiments of the system 1100 (FIG. 2, for example, thelifecycle management component 2110, the analytics component 2112, themonitoring and security component 2114, and/or the registration andconfiguration component 2116.

FIG. 69 depicts a schematic diagram of an example apparatus 69100 for anIoT device registry, e.g., for network connected devices 1112, 1114,1116, 1118, 1120, 1122, 1124 (FIG. 1), in accordance with an embodimentof the current disclosure. The apparatus 69100 may form part of theserver 1126 (FIG. 1), e.g., the at least one processor, and/or any otherelectronic computing device described herein.

With reference to FIG. 69, the apparatus 69100 is for an IoT deviceregistry. The apparatus 69100 may include a property-monitoring circuit69102. The property-monitoring circuit 69102 may be structured togenerate a query 69104 for device property data 69106 for an Internet ofThings (IoT) device to an IoT device registrar server, interpret thedevice property data 69106 received from the IoT device registrar serverto determine whether there is a change 69108 in the device propertydata, if the property-monitoring circuit determines that there is achange 69108 in the device property data 69106, generate a notificationof the change 69110, and transmit the notification of the change 69110to the IoT device registrar server.

Certain further aspects of the example apparatus are described herein,any one or more of which may be present in certain embodiments. Withfurther reference to FIG. 69, in the apparatus 69100, the query 69104may be initiated by at least one of: the device, a user of the device, aseller of the device, a purchaser of the device, a manufacturer of thedevice, or the IoT device registrar server. In the apparatus 69100, thechange may be determined by analyzing historical device property data69112 in the device property data 69106. In the apparatus 69100, thechange 69108 may be determined by monitoring a device property changeflag. In the apparatus 69100, the change 69108 may include a change indevice hardware. In the apparatus 69100, the change 69108 may include achange in a network. In the apparatus 69100, the change 69108 mayinclude a change in ownership of the device. In the apparatus 69100, thechange 69108 may include a security event. In the apparatus 69100, thedetermining that the device has reached end-of-life may includereceiving a user input 69114 indicating that the device has reachedend-of-life. In the apparatus 69100, the determining that the device hasreached end-of-life may include receiving a security notification 69116indicating a device decommissioning. In the apparatus 69100, thedetermining that the device has reached end-of-life may includereceiving a decommission notification 69118 indicating a devicedecommissioning. In the apparatus 69100, the property-monitoring circuit69102 may be further structured to generate a quarantine value 69120indicating that a device should be quarantined. In the apparatus 69100,the property-monitoring circuit 69102 may be further structured togenerate a decommission value 69122 indicating that a device should bedecommissioned. In the apparatus 69100, the property-monitoring circuit69102 may be further structured to generate a security value 69124indicating that a device may be subject to a security event. In theapparatus 69100, the property-monitoring circuit 69102 may be furtherstructured to generate an ownership notification 69126 indicating thatan ownership value corresponding to the device has changed. Theapparatus 69100 may further include a display circuit 69128 structuredto display the notification of the change. In the apparatus 69100, thedisplay circuit may be an SPG display circuit 69130 included in a SinglePane of Glass (SPG) system 69132. In the apparatus 69100, the SPG systemmay include a graphical user interface. In the apparatus 69100, thegraphical user interface may be hosted by an IoT device registrar thatincludes the IoT device registrar server. In the apparatus 69100, theSPG system 69132 may be included in a device management platform. In theapparatus 69100, the SPG system 69132 may include an ApplicationPrograming Interface (API) 69134. In the apparatus 69100, the API 69134may be hosted by the IoT device registrar. In the apparatus 69100, theAPI 69134 may be included in a device management platform.

FIG. 70 illustrates a flowchart of an example method 70100 fordisplaying IoT device registry data, e.g., for network connected devices1112, 1114, 1116, 1118, 1120, 1122, 1124 (FIG. 1), in accordance with anembodiment of the current disclosure. The method 70100 may be performedby the apparatus 69100 and/or any other computing device describedherein. The method 70100 may include generating a query for deviceproperty data for an Internet of Things (IoT) device to an IoT deviceregistrar server 70102. The method 70100 may further includeinterpreting the device property data received from the IoT deviceregistrar server to determine whether there is a change in the deviceproperty data 70104. The method 70100 may further include, if it isdetermined that there is a change in the device property data,generating a notification of the change 70106. The method 70100 mayfurther include transmitting the notification of the change to the IoTdevice registrar server 70108.

FIG. 71 is another flowchart depicting a method for an IoT deviceregistry display, in accordance with an embodiment of the currentdisclosure. Certain further aspects of the example method are describedherein, any one or more of which may be present in certain embodiments.The features shown in FIGS. 70 and 71 are combinable and interchangeablein any configuration in embodiments. With reference to FIG. 71, in themethod 70100, the query may be initiated by at least one of: the device,a user of the device, a seller of the device, a purchaser of the device,a manufacturer of the device, or the IoT device registrar server. In themethod 70100, the change may be determined by analyzing historicaldevice property data 71102. In the method 70100, the change may bedetermined by monitoring a device property change flag 71104. In themethod 70100, the change may include a change in device hardware. In themethod 70100, the change may include a change in a network. In themethod 70100, the change may include a change in ownership of thedevice. In the method 70100, the change may include a security event. Inthe method 70100, the determining that the device has reachedend-of-life may include receiving a user input indicating that thedevice has reached end-of-life 71106. In the method 70100, thedetermining that the device has reached end-of-life may includereceiving a security notification indicating a device decommissioning71108. In the method 70100, the determining that the device has reachedend-of-life may include receiving a decommission notification indicatinga device decommissioning 71110. The method 70100 may further includegenerating a quarantine value indicating that a device should bequarantined 71112. The method 70100 may further include generating adecommission value indicating that a device should be decommissioned71114. The method 70100 may further include generating a security valueindicating that a device may be subject to a security event 71116. Themethod 70100 may further include generating an ownership notificationindicating that an ownership value corresponding to the device haschanged 71118. The method 70100 may further include displaying thenotification of the change via a display circuit 71120. In the method70100, the notification of the change may be displayed via a Single Paneof Glass (SPG) system. In the method 70100, the SPG system may include agraphical user interface. In the method 70100, the graphical userinterface may be hosted by an IoT device registrar that includes the IoTdevice registrar server. In the method 70100, the SPG system may beincluded in a device management platform. In the method 70100, the SPGsystem may include an Application Programing Interface (API). In themethod 70100, the API may be hosted by the IoT device registrar. In themethod 70100, the API may be included in a device management platform.

FIG. 72 illustrates a flowchart of an example method 72100 fordisplaying IoT device registry data, e.g., for network connected devices1112, 1114, 1116, 1118, 1120, 1122, 1124 (FIG. 1), in accordance with anembodiment of the current disclosure. The method 72100 may be performedby the apparatus 69100 and/or any other computing device describedherein. The method 72100 may include determining that a device hasreached end-of-life 72102. The method 72100 may further includegenerating a query for IoT UID data corresponding to the device to anIoT device registrar server 72104. The method 72100 may further includeinterpreting IoT UID data received from the IoT device registrar serverto identify a set of IoT UIDs corresponding to the device 72106. Themethod 72100 may further include identifying a first UID list comprisinga first subset of the set of IoT UIDs to be reused 72108. The method72100 may further include identifying a second UID list comprising asecond subset of the set of IoT UIDs, different from the first subset,to be retired 72110. The method 72100 may further include transmittingthe first UID list and the second UID list to the IoT device registrarserver 72112.

FIG. 73 is another flowchart depicting a method for an IoT deviceregistry display, in accordance with an embodiment of the currentdisclosure. Certain further aspects of the example method are describedherein, any one or more of which may be present in certain embodiments.The features shown in FIGS. 72 and 73 are combinable and interchangeablein any configuration in embodiments. With reference to FIG. 73, in themethod 72100, either of the first subset or the second subset of the setof IoT UIDs may be an empty subset. The method 72100 may further includestoring the second UID list, comprising the second subset of the set ofIoT UIDs to be retired in a global retired UID registry, in the IoTdevice registrar server 73102. In the method 72100, the determining thatthe device has reached end-of-life may include receiving a user inputindicating that the device has reached end-of-life 73104. In the method72100, the determining that the device has reached end-of-life mayinclude receiving a security notification indicating a devicedecommissioning 73106. In the method 72100, the determining that thedevice has reached end-of-life may include receiving a decommissionnotification indicating a device decommissioning 73108.

FIG. 74 depicts a schematic diagram of an example apparatus 74100 for anIoT device registry, e.g., for network connected devices 1112, 1114,1116, 1118, 1120, 1122, 1124 (FIG. 1), in accordance with an embodimentof the current disclosure. The apparatus 74100 may form part of theserver 1126 (FIG. 1), e.g., the at least one processor, and/or any otherelectronic computing device described herein.

With reference to FIG. 74, the apparatus 74100 is for an IoT deviceregistry. The apparatus 74100 may include a device retirement circuit74102, a query-generating circuit 74104, an IoT UID interpretationcircuit 74106, and a retirement reporting circuit 74108. The deviceretirement circuit 74102 may be structured to determine that a devicehas reached end-of-life. The query-generating circuit 74104 may bestructured to generate a query 74110 for IoT UID data 74112corresponding to the device to an IoT device registrar server, e.g., theserver 1126 in the registrar 1130 (FIG. 1). The IoT UID interpretationcircuit 74106 may be structured to interpret the IoT UID data 74112received from the IoT device registrar server to identify a set of IoTUIDs 74114 corresponding to the device, identify a first UID list 74116comprising a first subset of the set of IoT UIDs 74114 to be reused, andidentify a second UID list 74118 comprising a second subset of the setof IoT UIDs 74114, different from the first subset, to be retired. Theretirement reporting circuit 74108 may be structured to transmit thefirst UID list 74116 and the second UID list 74118 to the IoT deviceregistrar server. In embodiments, an IoT UID may not be recycled, e.g.,an IoT UID may be permanently retired. In embodiments, an IoT UID may berecycled, e.g., a first device corresponding to an IoT UID may bedecommissioned and a second device may be assigned the IoT UID.

Certain further aspects of the example apparatus are described herein,any one or more of which may be present in certain embodiments. Withfurther reference to FIG. 74, in the apparatus 74100, either of thefirst subset or the second subset of the set of IoT UIDs may be an emptysubset. In the apparatus 74100, the second UID list, including thesecond subset of the set of IoT UIDs to be retired in a global retiredUID registry, may be stored in the IoT device registrar server. In theapparatus 74100, the determining that the device has reached end-of-lifemay include receiving a user input 74120 indicating that the device hasreached end-of-life. In the apparatus 74100, the determining that thedevice has reached end-of-life may include receiving a securitynotification 74122 indicating a device decommissioning. In the apparatus74100, the determining that the device has reached end-of-life mayinclude receiving a decommission notification 74124 indicating a devicedecommissioning.

FIG. 75 illustrates a flowchart of an example method 75100 fordisplaying IoT device registry data, e.g., for network connected devices1112, 1114, 1116, 1118, 1120, 1122, 1124 (FIG. 1), in accordance with anembodiment of the current disclosure. The method 75100 may be performedby the apparatus 69100 and/or any other computing device describedherein. The method 75100 may include interpreting, via a user inputprocessing circuit, a user input identifying a device to be retired75102. The method 75100 may further include generating a query forInternet of Things Universal Identification (IoT UID) data correspondingto the device to an IoT device registrar server 75104. The method 75100may further include interpreting IoT UID data received from the IoTdevice registrar server to identify a set of IoT UIDs corresponding tothe device 75106. The method 75100 may further include identifying afirst UID list comprising a first subset of the set of IoT UIDs to bereused 75108. The method 75100 may further include identifying a secondUID list comprising a second subset of the set of IoT UIDs, differentfrom the first subset, to be retired 75110. The method 75100 may furtherinclude transmitting the first UID list and the second UID list to theIoT device registrar server 75112. The method 75100 may further includeinterpreting, via the IoT device registrar server, the first UID listand the second UID list corresponding to the device 75114. The method75100 may further include displaying, via a display circuit, the firstUID list and the second UID list corresponding to the device 75116.

Certain further aspects of the example method are described herein, anyone or more of which may be present in certain embodiments. With furtherreference to FIG. 75, in the method 75100, either of the first subset orthe second subset of the set of IoT UIDs is an empty subset. The method75100 may further include storing the second UID list, comprising thesecond subset of the set of IoT UIDs to be retired in a global retiredUID registry, in the IoT device registrar server 75118.

FIG. 76 depicts a schematic diagram of an example apparatus 76100 for anIoT device registry, e.g., for network connected devices 1112, 1114,1116, 1118, 1120, 1122, 1124 (FIG. 1), in accordance with an embodimentof the current disclosure. The apparatus 76100 may form part of theserver 1126 (FIG. 1), e.g., the at least one processor, and/or any otherelectronic computing device described herein.

With reference to FIG. 76, the apparatus 76100 is for an IoT deviceregistry. The apparatus 76100 may include a user input processingcircuit 76102, a query-generating circuit 76104, an IoT UIDinterpretation circuit 76106, a device end-of-life interpretationcircuit 76107, and a display circuit 76110. The user input processingcircuit 76102 may be structured to interpret a user input 76112identifying a device to be retired. The query-generating circuit 76104may be structured to generate a query 76114 for IoT UID data 76116corresponding to the device to an IoT device registrar server, e.g., theserver 1126 in the registrar 1130 (FIG. 1). The IoT UID interpretationcircuit 76106 may be structured to interpret the IoT UID data 76116received from the IoT device registrar server to identify a set of IoTUIDs 76118 corresponding to the device, identify a first UID list 76120comprising a first subset of the set of IoT UIDs to be reused, andidentify a second UID list 76122 comprising a second subset of the setof IoT UIDs, different from the first subset, to be retired. The deviceend-of-life interpretation circuit 76108 may be at the IoT deviceregistrar server, and may be structured to interpret the first UID list76120 and the second UID list 76122 corresponding to the device. Thedisplay circuit 76110 may be structured to display the first UID list76120 and the second UID list 76122 corresponding to the device.

Certain further aspects of the example method are described herein, anyone or more of which may be present in certain embodiments. With furtherreference to FIG. 76, in the apparatus 76100, either of the first subsetor the second subset of the set of IoT UIDs is an empty subset. In theapparatus 76100, the second UID list, comprising the second subset ofthe set of IoT UIDs to be retired in a global retired UID registry, isstored in the IoT device registrar server.

FIG. 77 illustrates a flowchart of an example method 77100 fordisplaying IoT device registry data, e.g., for network connected devices1112, 1114, 1116, 1118, 1120, 1122, 1124 (FIG. 1), in accordance with anembodiment of the current disclosure. The method 77100 may be performedby the apparatus 69100 and/or any other computing device describedherein. The method 77100 may include interpreting, via an inputprocessing circuit, a device property data update request for an IoTdevice 77102. The method 77100 may further include determining, via anIoT UID identification circuit, one or more IoT UIDs corresponding tothe IoT device, based at least in part on the device property dataupdate request 77104. The method 77100 may further include generating,via a device lookup circuit, a query that includes the one or more IoTUIDs 77106. The method 77100 may further include retrieving, via thedevice lookup circuit, first device property data corresponding to theone or more IoT UIDs 77108. The method 77100 may further includetransmitting, via a query provisioning circuit, the query to an IoTdevice registrar server 77110. The method 77100 may further includeinterpreting, via a device property processing circuit, the deviceproperty data generated by the IoT UID server in response to the query,the device property data being included in a device entry in the IoT UIDserver corresponding to the IoT device 77112. The method 77100 mayfurther include generating, via the query provisioning circuit, arequest to the device for second device property data 77114. The method77100 may further include receiving, via the query provisioning circuit,the second device property data from the device in response to therequest 77116. The method 77100 may further include transmitting, viathe query provisioning circuit, the updated device property data to theIoT device registrar server in response to the request to at least oneof: replace at least a portion of the first device property data withthe second device property data in the device entry in the IoT deviceregistrar server, or add the second device property data to the deviceentry in the IoT device registrar server 77118. The method 77100 mayfurther include interpreting, via the device property processingcircuit, a comparison between the device property data the updateddevice property data 77120. The method 77100 may further includedisplaying, via a display circuit, a result of the comparison betweenthe device property data the updated device property data 77122.

FIG. 78 depicts a schematic diagram of an example apparatus 78100 for anIoT device registry, e.g., for network connected devices 1112, 1114,1116, 1118, 1120, 1122, 1124 (FIG. 1), in accordance with an embodimentof the current disclosure. The apparatus 78100 may form part of theserver 1126 (FIG. 1), e.g., the at least one processor, and/or any otherelectronic computing device described herein.

With reference to FIG. 78, the apparatus 78100 is for an IoT deviceregistry. The apparatus 78100 may include an input processing circuit78102, an IoT UID identification circuit 78104, a device lookup circuit78106, a query provisioning circuit 78108, a device property processingcircuit 78110, and a display circuit 78112.

The input processing circuit 78102 may be structured to interpret adevice property data update request 78114 for an IoT device. The IoT UIDidentification circuit 78104 may be structured to determine one or moreIoT UIDs 78116 corresponding to the IoT device, based at least in parton the device property data update request 78114. The device lookupcircuit 78106 may be structured to generate a query 78118 that includesthe one or more IoT UIDs 78116, and retrieve first device property data78120 corresponding to the one or more IoT UIDs 78116. The queryprovisioning circuit 78108 structured to transmit the query 78118 to anIoT device registrar server, e.g., the server 1126 in the registrar 1130(FIG. 1). The device property processing circuit 78110 may be structuredto interpret the first device property data 78120 generated by the IoTUID server in response to the query 78118, the first device propertydata 78120 being included in a device entry in the IoT UID servercorresponding to the IoT device. The query provisioning circuit 78108may be further structured to generate a first request 78122 to thedevice for second device property data 78124, receive the second deviceproperty data 78124 from the device in response to the first request78122, and transmit the second device property data 78124 to the IoTdevice registrar server in response to a second request 78126 to atleast one of: replace at least a portion of the first device propertydata 78120 with the second device property data 78124 in the deviceentry in the IoT device registrar server, or add the second deviceproperty data 78124 to the device entry in the IoT device registrarserver. The device property processing circuit 78110 may be furtherstructured to interpret a comparison between the first device propertydata 78120 and the second device property data 78124. The displaycircuit 78112 may be structured to display a result of the comparisonbetween the first device property data 78120 and the second deviceproperty data 78124.

FIG. 79 depicts a schematic diagram of an example apparatus 79100 for anIoT device registry, e.g., for network connected devices 1112, 1114,1116, 1118, 1120, 1122, 1124 (FIG. 1), in accordance with an embodimentof the current disclosure. The apparatus 79100 may form part of theserver 1126 (FIG. 1), e.g., the at least one processor, and/or any otherelectronic computing device described herein.

With reference to FIG. 79, the apparatus 79100 is for an IoT deviceregistry. The apparatus 79100 may include an event data processingcircuit 79102, an event detection circuit 79104, and a record managementcircuit 79106. The event data processing circuit 79102 may be structuredto interpret an IoT UID 79108 and corresponding device property data79110. The event detection circuit 79104 may be structured to determine,based at least in part on the device property data 79110, an event 79112corresponding to a device corresponding to the IoT UID 79108. The recordmanagement circuit 79106 may be structured to update a record 79114corresponding to the IoT UID 79108, based at least in part on the event79112.

Certain further aspects of the example apparatus are described herein,any one or more of which may be present in certain embodiments. Withfurther reference to FIG. 79, in the apparatus 79100, the event 79112may include determining that the device has reached end-of-life. In theapparatus 79100, the determining that the device has reached end-of-lifemay include receiving a user input 79116 indicating that the device hasreached end-of-life. In the apparatus 79100, the determining that thedevice has reached end-of-life may include receiving a securitynotification 79118 indicating a device decommissioning. In the apparatus79100, the determining that the device has reached end-of-life mayinclude receiving a decommission notification 79120 indicating a devicedecommissioning.

Embodiments of the current disclosure may provide for continuous IoTidentity lifecycle management. FIG. 80 is a schematic diagram depictinga lifecycle of network connected devices, in accordance with anembodiment of the current disclosure. For example, multiple networkconnected devices, e.g., ten, one-hundred, one-thousand, ten-thousand,etc., owned and/or operated by an entity, e.g., 1134 (FIG. 1), may eachbe assigned 80102 network connected device property data 6124 (FIG. 6),e.g., a device ID, and then be registered in bulk with the registrationserver 1126 (FIG. 1), as described herein. As shown in FIG. 80,embodiments of the system 1100 (FIG. 1) may provide for patching of thenetwork connected devices, e.g., the pushing of software and/or securityupdates to the devices. Embodiments of the current disclosure may alsotrack the patched status of the devices via one or more fields 6122(FIG. 6) within records 6110 (FIG. 6) corresponding to the networkconnected devices. Embodiments of the current disclosure may furtherprovide for configuration and/or permission changes to be applied to theconnected network devices, and/or provide for tracking of theconfiguration and/or permission settings of the network connected devicevia one or more fields 6122 (FIG. 6) in records 6110 (FIG. 6)corresponding to the network connected devices. Embodiments of thecurrent disclosure may also provide for network connected devices to beactivated and/or suspended 80104, transferred 80106 between ownersand/or operators of the network connected devices, and/or retired 80108from service. In certain aspects, transfers of a network connecteddevice may occur between owners, workgroups within the sameorganization, and/or other entities.

Embodiments of the current disclosure may also provide for alertmanagement 80110, e.g., the setting and triggering of alerts based onconditional logic. For example, the owner and/or operators of a networkconnected device may set alerts configured to notify the owner and/oroperator of unusual activity associated with one or more networkconnected devices. Embodiments of the current disclosure may alsoprovide for analytical analysis of data corresponding to the networkconnected devices, e.g., usage and/or trend data, risk management data,data compliance management, etc. Such analysis may be performed by theregistration server 1126 (FIG. 1) on data retrieved from the pluralityof records 1131 (FIG. 1). Risk analysis may be based at least in part onthe attributes of one or more network connected devices, e.g., lifecycleevents reflected by changes of a network connected device's attributesas recorded in its corresponding record 6110 (FIG. 6). The determinationof when to send an alert may be made automatically by the server 1126(FIG. 1) or by any apparatus described herein, or may be triggered by auser input.

FIG. 81 is a diagram mapping features to benefits of the system of FIG.1, in accordance with an embodiment of the current disclosure. Withreference to FIG. 81, as explained in greater detail herein, embodimentsof the current disclosure may provide various functions 81110, withrespect to network connected devices, such as verification 81112,defense 81114, recovery 81116, monitoring and/or control 81118, etc.Verification 81112 may include the confirmation of a network connecteddevice's identity and/or ownership. Defense 81114 may include theprevention of malware downloads (and or other network infiltrationmethods) and/or the malicious configuration of a network connecteddevice. Recovery 81116 may include restoration of a network connecteddevice to factory settings and/or another saved/known state. Recovery81116 may also include quarantining compromised devices and/or devicessuspected of being compromised. Monitoring and/or control 81118 mayinclude detection of anomalies regarding one or more network connecteddevices, management of a network connected device's lifecycle, and/oranalysis of trends involving one or more network connected devices.Non-limiting examples of anomalies include: out-of-range values for anattribute, e.g., temperatures, pressures, etc., monitored and/orexperienced by a network connected device and/or an asset beingmonitored by the network connected device; attempts to register anetwork connected device with the registry 1129 (FIG. 1) without havingapproval to do so; attempts by a network connected device to accessanother device and/or to exercise unauthorized network and/or deviceaccess permission; and/or other suspicious activities.

The functions 81110 may provide corresponding value, e.g., benefits81120, such as a trusted device identity registry 81122 that supportssecure provisioning and management of network connected deviceidentities, trusted two-way authentication 81124 before initiatingsecure downloads, identity-based segmentation and maintenance 81126,and/or identity lifecycle management and governance 81128 (which mayhelp an entity, e.g., 1134 (FIG. 1), operating a large number of networkconnected devices to ensure compliance with applicable regulations,e.g., data privacy laws with respect to data generated by a networkconnected device).

As will be understood, security in traditional IoT networks is oftenlacking and/or non-existent due to lack of expertise and/or educationregarding IoT security within an enterprise, e.g., a corporate network.When security is considered by an enterprise, it is often anafterthought or considered non-critical when compared to the incentivesof launching a new IoT solution early in the marketplace. Lack ofexperience by an enterprise and/or a failure to understand and/orappreciate IoT security may cause an enterprise to hire a third party toconduct a security assessment/inspection. Such assessments, however, donot provide continuous security. Further, the resources required tomanage IoT device lifecycles and security generally scale exponentially.As will be understood, lifecycle management of network connecteddevices, and the corresponding infrastructure disclosed herein, may easeand/or otherwise improve security and/or risk management of networkconnected devices, to include easing and/or improving the ability of anentity that owns or operates network connected devices to comply withgovernment and/or industry standards. For example, in certain aspects,the registry 1129 (FIG. 1) may provide for verification of an ownerand/or operator of a registered network connected device beforemodifying the corresponding record. Such verification may mitigateand/or prevent the likelihood of a spoofing attack on the networkconnected device. Thus, some embodiments of the current disclosure maymitigate the threat of a network intruder/masquerader and/or provide forthe ability to detect such an intruder in the event one gains access tonetwork connected device and/or corresponding network. The registry 1129may also provide for the ability to detect tampering of a networkconnected device, e.g., buy looking for unusual activities within thecorresponding records 1131. Some embodiments of the registry 1129 mayprovide for the correction of a tampered device.

FIG. 82 is a process flow diagram depicting process flows for lifecyclemanagement of IoT devices, in accordance with embodiments of the currentdisclosure. Illustrated in FIG. 82 is a process flow diagram depicting aprocess flow 82100 for lifecycle management of registered IoT devicesinvolving the exchange of data between: a device 82112, e.g., anenterprise end user 1136 (FIG. 1), a could platform 82114, a devicemanagement partner platform 82116; a single pane of glass (SPG) 82118;an ecosystem 82120, one or more networks 82122, and an IoT deviceregistrar, e.g., the IoT device registrar 1130 of FIG. 1. The flow 82100may apply, for example, to a Greenfield device having an embedded IoTUID, as described herein, e.g., FIGS. 40 and 41 and related disclosure.The ecosystem 82120 may include the ecosystems 1134 in which the one ormore devices 1112, 1114, 1116, 1118, 1120, 1122, and 1124 exist/operate(FIG. 1), ecosystems SO5126 that may relate to risk management SO5128,compliance management SO5130, and/or security SO5132 (FIG. SO5), and mayfurther include one or more databases that may store informationregarding known vulnerabilities of IoT devices registered in theregistry 1129 (FIG. 1). Information on risk events may be pulled fromthe databases in the ecosystem.

With further reference to FIG. 82, in embodiments, in flow 82100 thecloud platform 82114 may adjust and/or manipulate the data planefunctionality of the device 82112, as depicted by line 82124. The devicemanagement partner platform 82116 may adjust and/or manipulate thecontrol plane functionality of the device 82112, as depicted by line82126. When the communication at 82124 and 82126 are established, it canbe confirmed at 82128 that the device 82112 is operational.

The flow 82100 may then include flow 82110. In flow 82110, as depictedby dashed line 82130, notifications and information on events, asdescribed herein, may be transmitted to/from the IoT device registrar1130 and devices and databases in the ecosystem 82120. In addition, inflow 82110, as depicted by dashed line 82132, notifications andinformation on events, as described herein, may be transmitted to/fromthe IoT device registrar 1130 and the one or more networks 82122. Inflow 82110, as depicted by line 82134, a notification of a firmwareupdate, e.g., module/chipset/device types, may be transmitted from theecosystem 82120 to the IoT device registrar 1130.

Next, in flow 82110, as depicted by line 82136, IoT device registrar1130 may identify an IoT UID associated with the device 82112, and maytransmit the firmware update and the IoT UID to the device managementpartner platform 82116, for example, by piggybacking the IoT UID onto amessage containing the firmware update, as described herein, e.g., FIGS.30 and 31 and related disclosure. Then, in flow 82110, as depicted byline 82138, the device management partner platform 82116 may trigger thedevice 82112 to implement the firmware update transmitted with theassociated IoT UID.

With further reference to FIG. 82, in flow 82110, as depicted by line82140, the one or more networks 82122 may transmit a device attributechange to the IoT device registrar 1130. The device attribute change maybe indicative of a security event, as described herein. The deviceattribute change may also be a defensive notification from the ecosystem82120 and/or the one or more networks 82122 to be sent to the IoT deviceregistrar 1130 indicating that a security event has been identified.Next, in flow 82110, as depicted by line 82142, the IoT device registrar1130 may generate a security signal event notification indicating thesecurity event, and may identify an IoT UID associated with the device82112, and then may transmit the security signal event notification andthe IoT UID to the device management partner platform 82116, forexample, by piggybacking the IoT UID onto a message containing asecurity signal event notification, as described herein. Then, in flow82110, as depicted by line 82144, the IoT device registrar 1130 may sendthe security signal event notification to the SPG 82118, e.g., to bedisplayed. Also, in flow 82110, as depicted by line 82146, when thedevice management partner platform 82116 receives the security signalevent notification and the IoT UID, it may trigger one or more securityactions, such as quarantining the device 82112, disabling the device82112, notifying the device 82112 of the security event, or otheractions as described herein. In flow 82110, as depicted by line 82148,the IoT device registrar 1130 may transmit the security signal eventnotification and the IoT UID to the cloud platform 82114; then, asdepicted by line 82150, the IoT device registrar 1130 may transmit thesecurity signal event notification to the SPG 82118, e.g., to bedisplayed. In flow 82110, as depicted by line 82152, when the cloudplatform 82114 receives the security signal event notification, it maytrigger one or more security actions, such as quarantining the device82112, disabling the device 82112, notifying the device 82112 of thesecurity event, or other actions as described herein.

FIG. 83 is another process flow diagram depicting process flows forlifecycle management of IoT devices, in accordance with embodiments ofthe current disclosure. Illustrated in FIG. 83 is a process flow diagramdepicting a process flow 83100 for lifecycle management of registeredIoT devices involving the exchange of data between: a device 82112,e.g., an enterprise end user 1136 (FIG. 1), a could platform 82114, adevice management partner platform 82116; a single pane of glass (SPG)82118; an ecosystem 82120, one or more networks 82122, and an IoT deviceregistrar, e.g., the IoT device registrar 1130 of FIG. 1. The flow 82100may apply, for example, to a Greenfield device having a virtual IoT UIDand/or to a Brownfield device having an embedded IoT UID, as describedherein. The ecosystem 82120 may include the ecosystems 1134 in which theone or more devices 1112, 1114, 1116, 1118, 1120, 1122, and 1124exist/operate (FIG. 1), ecosystems 5126 that may relate to riskmanagement 5128, compliance management 5130, and/or security 5132 (FIG.5), and may further include one or more databases that may storeinformation regarding known vulnerabilities of IoT devices registered inthe registry 1129 (FIG. 1). Information on risk events may be pulledfrom the databases in the ecosystem.

With further reference to FIG. 83, in embodiments, in flow 83100 thecloud platform 82114 may adjust and/or manipulate the data planefunctionality of the device 82112, as depicted by line 82124, which maybe the same as shown in FIG. 82. The device management partner platform82116 may adjust and/or manipulate the control plane functionality ofthe device 82112, as depicted by line 82126, which may be the same asshown in FIG. 82. When the communication at 82124 and 82126 areestablished, it can be confirmed at 82128 that the device 82112 isoperational, which may be the same as shown in FIG. 82.

The flow 83100 may then include flow 83102, which may include flow 83104and flow 83106. In flow 83102, as depicted by dashed line 83110,notifications and information on events, as described herein, may betransmitted to/from the IoT device registrar 1130 and devices anddatabases in the ecosystem 82120. In addition, in flow 83102, asdepicted by dashed line 83112, notifications and information on events,as described herein, may be transmitted to/from the IoT device registrar1130 and the one or more networks 82122.

With further reference to FIG. 83, in flow 83104, as depicted by line83114, a notification of a firmware update, e.g., module/chipset/devicetypes, may be transmitted from the ecosystem 82120 to the IoT deviceregistrar 1130.

Next, in flow 83104, as depicted by line 83116, IoT device registrar1130 may associate the module/chipset/device type of the notificationwith one or more IoT UIDs.

Subsequently, in flow 83104, as depicted by line 83118, IoT deviceregistrar 1130 may associate the IoT UIDs with the device type of thedevice 82112 and/or modules in the device 82112 that should receive thefirmware update, and may transmit the firmware update and the IoT UIDsand/or the device and/or module type to the device management partnerplatform 82116, for example, by piggybacking the IoT UID onto a messagecontaining the firmware update, as described herein. Then, in flow83104, as depicted by line 83120, the device management partner platform82116 may trigger the device 82112 to implement the firmware updatetransmitted with the associated IoT UID. Next, in flow 83104, asdepicted by line 83122, the device 82112 may apply the firmware update.Subsequently, in flow 83104, as depicted by line 83124, device 82112 maysend a notification to the device management partner platform 82116 thatthe firmware update was successfully applied. Then, in flow 83104, asdepicted by line 83126, the device management partner platform 82116 maysend a notification to the IoT device registrar 1130 that the firmwareupdate was successfully applied. Next, in flow 83104, as depicted byline 83128, the IoT device registrar 1130 may update a trustlevel/rating/score associated with the IoT UID, based on the successfulfirmware update.

With further reference to FIG. 83, in flow 83106, as depicted by line83130, the one or more networks 82122 may transmit a device attributechange to the IoT device registrar 1130. The device attribute change maybe indicative of a security event, as described herein. The deviceattribute change may also be a defensive notification from the ecosystem82120 and/or the one or more networks 82122 to be sent to the IoT deviceregistrar 1130 indicating that a security event has been identified.Then, in flow 83106, as depicted by line 83132, the IoT device registrar1130 may associate a device type with one or more IoT UIDs, and mayassociate one or more IoT UIDs with the security event.

Next, in flow 83106, as depicted by line 83134, the IoT device registrar1130 may generate a security signal event notification indicating thesecurity event, and may notify the device management partner platform82116 of device types that are associated with the security event. Also,in flow 83106, as depicted by line 83136, the IoT device registrar 1130may send a notification to the SPG 82118 regarding the security eventand a list of IoT UIDs associated with the security event, which may bedisplayed by the SPG 82118. Also, in flow 83106, as depicted by line83138, when the device management partner platform 82116 receives thesecurity signal event notification, it may trigger one or more securityactions on the devices of the type associated with the security event,including the device 82112, such as quarantining the devices, disablingthe device, notifying the device of the security event, or other actionsas described herein.

In flow 83106, as depicted by line 83140, the IoT device registrar 1130may transmit the security signal event notification to the SPG 82118,e.g., to be displayed. In flow 83106, as depicted by line 83142, the IoTdevice registrar 1130 may transmit the security signal eventnotification, the device type associated with the security event, andthe IoT UID to the cloud platform 82114. In flow 83106, as depicted byline 83144, when the cloud platform 82114 receives the security signalevent notification, it may trigger one or more security actions on thedevices of the type associated with the security event, including thedevice 82112, such as quarantining the devices, disabling the device,notifying the device of the security event, or other actions asdescribed herein.

FIG. 84 is another process flow diagram depicting process flows forlifecycle management of IoT devices, in accordance with embodiments ofthe current disclosure. Illustrated in FIG. 84 is a process flow diagramdepicting a process flow 84100 for lifecycle management of registeredIoT devices involving the exchange of data between: a device 82112,e.g., an enterprise end user 1136 (FIG. 1), a could platform 82114, adevice management partner platform 82116; a single pane of glass (SPG)82118; an ecosystem 82120, one or more networks 82122, and an IoT deviceregistrar, e.g., the IoT device registrar 1130 of FIG. 1. The flow 82100may apply, for example, to a Brownfield device having a virtual IoT UID,as described herein. The ecosystem 82120 may include the ecosystems 1134in which the one or more devices 1112, 1114, 1116, 1118, 1120, 1122, and1124 exist/operate (FIG. 1), ecosystems 5126 that may relate to riskmanagement 5128, compliance management 5130, and/or security 5132 (FIG.5), and may further include one or more databases that may storeinformation regarding known vulnerabilities of IoT devices registered inthe registry 1129 (FIG. 1). Information on risk events may be pulledfrom the databases in the ecosystem.

With further reference to FIG. 84, in embodiments, in flow 84100 thecloud platform 82114 may adjust and/or manipulate the data planefunctionality of the device 82112, as depicted by line 82124, which maybe the same as shown in FIG. 82. The device management partner platform82116 may adjust and/or manipulate the control plane functionality ofthe device 82112, as depicted by line 82126, which may be the same asshown in FIG. 82. When the communication at 82124 and 82126 areestablished, it can be confirmed at 82128 that the device 82112 isoperational, which may be the same as shown in FIG. 82.

The flow 84100 may then include flow 84102, which may include flow 84104and flow 84106. In flow 84102, as depicted by dashed line 84110,notifications and information on events, as described herein, may betransmitted to/from the IoT device registrar 1130 and devices anddatabases in the ecosystem 82120. In addition, in flow 84102, asdepicted by dashed line 84112, notifications and information on events,as described herein, may be transmitted to/from the IoT device registrar1130 and the one or more networks 82122.

With further reference to FIG. 84, in flow 84104, as depicted by line84114, a notification of a firmware update, e.g., module/chipset/devicetypes, may be transmitted from the ecosystem 82120 to the IoT deviceregistrar 1130.

Next, in flow 84104, as depicted by line 84116, IoT device registrar1130 may associate the module/chipset/device type of the notificationwith one or more IoT UIDs.

Subsequently, in flow 84104, as depicted by line 84118, IoT deviceregistrar 1130 may associate the IoT UIDs with the device type of thedevice 82112 and/or modules in the device 82112 that should receive thefirmware update, and may transmit the firmware update and device and/ormodule type and/or the IoT UIDs to the device management partnerplatform 82116, for example, by piggybacking the information onto amessage containing the firmware update, as described herein. Then, inflow 84104, as depicted by line 84120, the device management partnerplatform 82116 may trigger the device 82112 to implement the firmwareupdate transmitted with the associated IoT UID. Next, in flow 84104, asdepicted by line 84122, the device 82112 may apply the firmware update.Subsequently, in flow 84104, as depicted by line 84124, device 82112 maysend a notification to the device management partner platform 82116 thatthe firmware update was successfully applied. Then, in flow 84104, asdepicted by line 84126, the device management partner platform 82116 maysend a notification to the IoT device registrar 1130 that the firmwareupdate was successfully applied. Next, in flow 84104, as depicted byline 84128, the IoT device registrar 1130 may update a trustlevel/rating/score associated with the IoT UID, based on the successfulfirmware update.

With further reference to FIG. 84, in flow 84106, as depicted by line84130, the one or more networks 82122 may transmit a device attributechange to the IoT device registrar 1130. The device attribute change maybe indicative of a security event, as described herein. The deviceattribute change may also be a defensive notification from the ecosystem82120 and/or the one or more networks 82122 to be sent to the IoT deviceregistrar 1130 indicating that a security event has been identified.Then, in flow 84106, as depicted by line 84132, the IoT device registrar1130 may associate a device type with one or more IoT UIDs, and mayassociate one or more IoT UIDs with the security event.

Next, in flow 84106, as depicted by line 84134, the IoT device registrar1130 may generate a security signal event notification indicating thesecurity event, and may notify the device management partner platform82116 of device types that are associated with the security event. Also,in flow 84106, as depicted by line 84136, the IoT device registrar 1130may send a notification to the SPG 82118 regarding the security eventand a list of IoT UIDs associated with the security event, which may bedisplayed by the SPG 82118. Also, in flow 84106, as depicted by line84138, when the device management partner platform 82116 receives thesecurity signal event notification, it may trigger one or more securityactions on the devices of the type associated with the security event,including the device 82112, such as quarantining the devices, disablingthe device, notifying the device of the security event, or other actionsas described herein.

In flow 84106, as depicted by line 84140, the IoT device registrar 1130may transmit the security signal event notification to the SPG 82118,e.g., to be displayed. In flow 84106, as depicted by line 84142, the IoTdevice registrar 1130 may transmit the security signal eventnotification and the device type associated with the security event,and/or the IoT UID, to the cloud platform 82114. In flow 84106, asdepicted by line 84144, when the cloud platform 82114 receives thesecurity signal event notification, it may trigger one or more securityactions on the devices of the type associated with the security event,including the device 82112, such as quarantining the devices, disablingthe device, notifying the device of the security event, or other actionsas described herein.

FIG. 85 is a component diagram of a system for managing one or moredevices, in accordance with an embodiment of the current disclosure.With reference to FIG. 85 and FIG. 2, embodiments of a system 85100managed by the registry 1129 (FIG. 1) may include the lifecyclemanagement component 2110, the analytics component 2112, the monitoringand security component 2114, and the registration and configurationcomponent 2116. The lifecycle management component 2110 may include atransfer and ownership subcomponent 2118, a troubleshoot and maintaindevices subcomponent 85110, and a suspend/activate/retire subcomponent85120, which may include the suspend and activate device subcomponent2110, and/or the retire device subcomponent 2122 of FIG. 2. Theanalytics component 2112 may include the device intelligencesubcomponent 2124, the government and risk management subcomponent 2126,and/or the data compliance management subcomponent 2128. The monitor andsecure component 2114 may include the usage and trend analysissubcomponent 2130, the detect unusual behavior subcomponent 2132, and/orthe set service alerts subcomponent 2134. The register and configurecomponent 2116 may include the relationships and permission subcomponent2136, the device ID definition subcomponent 2138, and/or the bulk uploadand connect subcomponent 2140. The bulk upload and connect subcomponent2140 may facilitate communication with network connected devices acrossmultiple cloud environments. The lifecycle management component 2110 mayinclude the apparatus 69100 or any other apparatus described herein, andmay perform the method 70100 or any other method described herein tomanage the lifecycle of an IoT device, for example, associated with anIoT UID.

In embodiments, lifecycle management may include performing statuschecks of devices and their current configuration states, e.g.,installed patches, installed hardware, number of active network cards,etc. Lifecycle management may include detecting changes in theproperties of a device, e.g., detecting and/or recording events. Eventsmay come, for example, from a device manager, a connection managementplatform (CMP), a Remote Authentication Dial-In User Service (RADIUS)feed (e.g., event stream), and/or a Home Location Register (HLR).Lifecycle management may include detecting security events. Lifecyclemanagement may include tracking of ownership changes in the IoT deviceregistry. Embodiments may provide for retirement of Greenfield and/orBrownfield devices, which may be real-world devices, virtual devices, ormeta-devices. Embodiments may monitor for instances in which apermanently retired immutable device property, e.g., an InternationalMobile Equipment Identity (IMEI), appears in another device. Embodimentsmay provide for reincarnation/reuse/recycling of old IoT UIDs and/or fortheir permanent retirement. Embodiments may provide for data “sanity”checks. For example, determining whether data from a device at 30%battery or less should be collected and/or considered trustworthy.Detection of a device's being down, e.g., unreachable, offline,inoperable, or otherwise unavailable, as disclosed herein, may beprovided by certain embodiments. Embodiments may facilitate the pushingof updates and/or patches to devices. Lifecyle management may includemodifying a trust indicator/level/score/rating of a device based onevents. Embodiments may decrease a device's trustindicator/level/score/rating value if the corresponding information inthe IoT device registry starts to get stale, e.g., has not been updatedand/or queried for at least a predetermined time. Embodiments mayprovide for polling of devices to provide updates to their storedproperty data.

Referring again to FIG. 1, embodiments of the current disclosure mayprovide for the maintaining/recording of chain of title for devices,e.g., devices 1112, 1114, 1116, 1118, 1120, 1122, and 1124, managed bythe registrar 1130, e.g., in the registry 1129. Embodiments may includemaintaining and/or recording the chain of title via a distributedledger, e.g., a blockchain. The chain of title may include ownershipdata for the device and/or for any modules in the device. Embodimentsmay allow a user to claim ownership of device and/or any modules in thedevice, as disclosed herein, e.g., via submitting a registration requestwith security credentials to the registry that identify a device andauthentication for the registering entity. Non-limiting examples of usertypes include one or more end users 1136, e.g., enterprise, manufacturer1134, e.g., an original equipment manufacturer (OEM) and/or factoryemployees, the IoT device registrar 1130, and/or a third party 1138. Thechain of title may be provided, e.g., displayed, by a Single Pane ofGlass (SPG), which may provide a graphical user interface (GUI), e.g.,any of GUIs 22108 (FIG. 22), 23108 (FIG. 23), 28102 (FIG. 28), 28104(FIG. 28), or 28106 (FIG. 28), for the user to interact with, such as toinput data, commands, and queries, as well as to display the IoTregistry data. The GUI may provide access to any of the embodiments ofthe system 1100 (FIG. 2), for example, the lifecycle managementcomponent 2110, the analytics component 2112, the monitoring andsecurity component 2114, and/or the registration and configurationcomponent 2116.

FIGS. 86, 87, and 88 depict schematic diagrams of an example apparatus86100 for an Internet of Things (IoT) device registry, e.g., for networkconnected devices 1112, 1114, 1116, 1118, 1120, 1122, 1124 (FIG. 1), inaccordance with an embodiment of the current disclosure. The apparatus86100 may form part of the server 1126 (FIG. 1), e.g., the at least oneprocessor, and/or any other electronic computing device describedherein.

With reference to FIG. 86, the apparatus 86100 is for an Internet ofThings (IoT) device registry. The apparatus 86100 may include anInternet of Things Universal Identification (IoT UID) processing circuit86102, a record management circuit 86104, an ownership analysis circuit9606, and an ownership provisioning circuit 86108. The IoT UIDprocessing circuit may be structured to interpret an IoT UID 9610corresponding to a device, e.g., any of devices 1112, 1114, 1116, 1118,1120, 1122, 1124 (FIG. 1). The record management circuit 86104 may bestructured to identify, based at least in part on the IoT UID 86110, arecord 86112 in a database, e.g., database 1128 (FIG. 1), the record86112 including device ownership data 9614 associated with the device.The ownership analysis circuit 86106 may be structured to interpret,based at least in part on the record, the device ownership data 86114associated with the device. The ownership provisioning circuit 86108 maybe structured to transmit the device ownership data 86114.

Certain further aspects of the example apparatus are described herein,any one or more of which may be present in certain embodiments. Thefeatures shown in FIGS. 86, 87, and 88 are combinable andinterchangeable in any configuration in embodiments. With furtherreference to FIG. 86, in the apparatus 86100, the device ownership datamay include a record of one or more entities 86116. In the apparatus86100, the record of one or more entities may include an historic recordof one or more entities that have owned the device. In the apparatus86100, the device ownership data may include a record of historicalownership 86118. The record of historical ownership 86118 may include alist of records each corresponding to a distinct owner of the device. Inembodiments, the record of historical ownership 86118 may be facilitatedby a blockchain. Embodiments of the historical ownership blockchain maybe a centralized blockchain, a decentralized blockchain, and/or acombination thereof. Embodiments of the current disclosure may usepublic and/or private blockchains. In embodiments, a record in the IoTdevice registry may include a pointer to a blockchain. In the apparatus86100, the device may include a plurality of modules, each module havingcorresponding ownership data, for example, an employee may have a laptopthat includes a corporate provided/owned encryption module, while theemployee owns the other modules in the laptop; an employee has theirpersonal mobile device, while their employer provides a SIM card forthat device to connect to a network; a home is owned by a privateperson, while the solar panels on the home are leased from an energyprovider; and/or a mining company may own devices forming part of a dumptruck while leasing the radio communication equipment in the dump truck.The apparatus 86100 may further include an access restriction circuit86120 structured to restrict access to information about the device froman owner of the device. In the apparatus 86100, the access restrictioncircuit 9620 may be further structured to restrict access to informationabout a first owner of the device from a second owner of the device. Inembodiments, such restrictions may be based at least in part on usertype and/or credentials. For example, an employee of a registeredcorporate cell phone may be prohibited from viewing the prior ownershiphistory of the cell phone, while the corporate employer may have accessto the prior ownership history. The apparatus 86100 may further includea display circuit 86122 structured to display the device ownership datafor the device. In embodiments, the display may form part of an SPG, asdisclosed herein. The apparatus 86100 may further include an ownershipdata update provisioning circuit 86124 structured to provide updatedownership data 86126 to replace the device ownership data 86114associated with the device. In the apparatus 86100, the device ownershipdata update provisioning circuit may be further structured to provideupdated ownership data 86126 for one or more modules of the device. Suchupdates may be provided via device event messages 6116 (FIG. 6). In theapparatus 86100, the updated ownership data may include a claim ofownership 86128 of the device. For example, a device may have beentransferred via a legal assignment from a first entity to a secondentity, wherein the first entity provides an event message to the IoTdevice registry informing the registry of the ownership transfer. Forexample, a smart contract that assigns one or more devices may send theIoT device registry and/or the device management platform an eventmessage when a portion of the smart contract transfers title of the oneor more devices to a party. In such a scenario, the IoT device registrymay update a record corresponding to the device such that the recordreflects that ownership has changed, but that the device needs to beclaimed by the second entity. The second entity may then perform anaction, e.g., turning on the device and/or making a registration requestvia an SPG, that triggers transmission of a registration request to theIoT device registry requesting registration of the device in the name ofthe second entity. Upon receipt of the registration request, and uponcompletion of any verification processes that may be performed by theIoT device registry to verify the second entity, the IoT device registrymay update the record to reflect that the second entity is the currentowner and that the device has been claimed. In the apparatus 86100,events resulting in the updated ownership data may include at least oneof: creation of the device, sale of the device, decommissioning of thedevice, transfer of ownership of the device, or licensing of the device.The apparatus 86100 may further include a security notificationprovisioning circuit 86130 structured to compare the device ownershipdata to a record of authorized owners 86132, and generate a securitynotification 86134 if the device ownership data is not included in therecord of authorized owners. In the apparatus 86100, the database mayinclude a blockchain. Non-limiting examples of device transfers includescenarios where: an old owner transfers ownership of a device to astockpile and/or spare collection; a new owner picks up ownership of adevice from a stockpile and/or spare collection; an old owner transfersa device directly to a new owner (where the old owner may have a meta-idof the new owner, as disclosed herein); a new owner transfers ownershipform an old owner (where the new owner has a meta-id of the old owner);an owner of a device remains the same but sub-owners of the devicechange.

With reference to FIG. 87, the apparatus 86100 may further include adevice theft notification circuit 87102 structured to certify that thedevice is not a stolen device. In embodiments, the notification circuit87102 may provide for a notification to appear on the device, e.g., agreen (not stolen) or red (appears to be stolen) check mark in a cornerof a screen, and/or on an SPG. The apparatus 86100 may further include adevice title certification circuit 87104 structured to certify that thedevice has a fully accountable chain of title. In embodiments, the titlecertification circuit 87104 may provide for a notification to appear onthe device, e.g., a green (verified good title) or red (apparent titlediscrepancies) check mark in a corner of a screen, and/or on an SPG. Thecertifying may be based on the record and/or the device ownership data.The apparatus 86100 may further include a trust indicator provisioningcircuit 87106 structured to provide a trust indicator 87108 for thedevice. The trust indicator may include, for example, at least one of ascore, a rating, or a level value. In the apparatus 86100, the trustindicator 87108 may include a numeric value. In the apparatus 86200, thetrust indicator 87108 may include an enumerated value. In the apparatus86100, the trust indicator 87108 may be displayed as a color-codedvalue. In the apparatus 86100, a value of the trust indicator 87108 maybe based at least in part on a location of the device. In the apparatus86100, a value of the trust indicator 87108 may be based at least inpart on a time period. In the apparatus 86100, a value of the trustindicator 87108 may be based at least in part on one or more of asoftware version or a firmware version of the device. In the apparatus86100, determining the trust indicator 87108 may be based at least inpart on artificial intelligence. In the apparatus 86100, the trustindicator 87108 may be reflective of the device being a Greenfielddevice. In the apparatus 86100, the trust indicator 87108 may bereflective of the device being a Brownfield device. In the apparatus86100 and/or 120100 (FIG. 120), the trust indicator may be reflective ofthe device being a virtual device, as disclosed herein. In the apparatus86100 and/or 120100 (FIG. 120), the trust indicator may be reflective ofthe device being a meta-device, as disclosed herein.

For example, devices may be virtual devices, e.g., objects in ametaverse having real-world counterparts (real-world devices), where thevirtual device is a digital-twin of the real-world counterpart. Adigital virtual device may have properties corresponding to itsreal-world counterpart that may be updated in real-time and/or on aperiodic basis. Devices in the metaverse may be real-world devices,e.g., objects in the real-world having metaverse counterparts (digitaltwin virtual devices) and/or supporting metaverse activities. As anotherexample, devices may be meta-devices, e.g., objects in the metaverselacking real-world counterparts. In embodiments, a device may havemodules that are virtual devices and modules that are meta-devices. Inembodiments, an IoT device registry may provide for registration ofvirtual devices, real-world devices, and/or meta-devices, as disclosedherein, and/or the services and/or functions associated withregistration for registered virtual devices, real-world devices, and/ormeta-devices, as also disclosed herein. Any of virtual devices,real-world devices, and/or meta-devices may be Greenfield devices and/orBrownfield devices, and/or may have a combination of Greenfield modulesand/or Brownfield modules.

In the apparatus 86100, the trust indicator 87108 may be displayed as atleast one of: numeric based, color based, symbol based, alphanumericbased, letter based, or any combination thereof. The apparatus 86100 mayfurther include an asking price evaluation circuit 87110 structured toevaluate an asking price 87112 for the device based on at least one of:the device ownership data 86114, a certification that the device is nota stolen device, or a certification that the device has a fullyaccountable chain of title. The certification that the device is not astolen device and/or the certification that the device has a fullyaccountable chain of title may be included in the record 86112 or in thedevice ownership data 86114, or may be provided from elsewhere, e.g.,from the IoT device registrar 1130 (FIG. 1). In the apparatus 86100, theasking price evaluation circuit 87110 may be further structured toevaluate an asking price 87112 for a group of devices based on ownershipdata for each device.

With reference to FIG. 88, the apparatus 801600 may further include asupply chain validation circuit 88102 structured to validate a supplychain 88104. In the apparatus 86100, the validating the supply chain mayinclude determining whether modules of the device were sourced fromauthorized vendors. Such determining may include walking or tracing thechain of title via the IoT device registry for one or more modules thatpassed through the supply chain to verify the original ownership throughthe most recent receiving entity and to verify that the verified ownersare compliant with one or more regulations and/or requirements, e.g.,government and/or Department of Defense/military regulations 2126 (FIG.2), medical regulations, and/or fair-trade rules. For example,embodiments of the current disclosure may provide for verification thata medical/surgical robot has been sourced and/or handled by trustedparties, thereby reducing the likelihood that the robot has defectivecomponents, can be compromised, and/or suffer a malfunction. As such, inthe apparatus 86100, validating the supply chain may include determiningwhether modules of the device were sourced from fair trade certifiedsources. The validation may be based on the device ownership data 86114,or may be based on data provided from elsewhere, e.g., from the IoTdevice registrar 1130 (FIG. 1), a device management platform, etc. Theapparatus 86100 may further include a carbon rating provisioning circuit88106 structured to provide a carbon rating 88108 of the device based onknown ratings of sources of modules of the device, determined based onthe device ownership data. For example, a carbon rating of a device maybe based at least in part on cumulative ratings of the manufacturers ofthe modules and/or the transportation systems that bring the modules tothe manufacturer for assembly into the device and/or the transportationsystems that bring the device to market. The apparatus 86100 may furtherinclude a device property detection circuit 88110 structured to detect adevice property 88112 that indicates a change in ownership data. Inembodiments, the device property detection circuit 88110 may bestructured to periodically inspect records in the IoT device registryand compare their corresponding device property data to correspondinghistorical data. In embodiments, a record in the registry may have amodified field that may be set, e.g., “true”, when a field in the recordhas been modified, as described herein, where the device propertydetection circuit 88110 may query the registry for records having a setmodified field. In such embodiments, the device property detectioncircuit 88110 may release/reset the modified field back to an unmodifiedstate, e.g., “false” after interpreting the corresponding deviceproperty data. In the apparatus 86100, the device property 88112 mayinclude a location 88114 of the device.

FIG. 89 illustrates a flowchart of an example method 89100 fordisplaying IoT device registry data, e.g., for network connected devices1112, 1114, 1116, 1118, 1120, 1122, 1124 (FIG. 1), in accordance with anembodiment of the current disclosure. The method 89100 may be performedby the apparatus 86100 and/or any other computing device describedherein.

The method 89100 may include interpreting, via an IoT UID processingcircuit, an IoT UID corresponding to a device 89102. The method mayfurther include identifying, via a record management circuit and basedat least in part on the IoT UID, a record in a database, the recordincluding device ownership data associated with the device 89104. Themethod may further include interpreting, via an ownership analysiscircuit and based at least in part on the record, the device ownershipdata 89106. The method may further include transmitting, via anownership provisioning circuit, the device ownership data 89108.

FIG. 90 is another flowchart depicting a method for an IoT deviceregistry display, in accordance with an embodiment of the currentdisclosure. FIG. 91 is another flowchart depicting a method for an IoTdevice registry display, in accordance with an embodiment of the currentdisclosure. Certain further aspects of the example method are describedherein, any one or more of which may be present in certain embodiments.The features shown in FIGS. 89, 90, and 91 are combinable andinterchangeable in any configuration in embodiments. In the method89100, the device ownership data may include a record of one or moreentities. In the method 89100, the record of one or more entities mayinclude an historic record of one or more entities that have owned thedevice. In the method 89100, the device ownership data may include arecord of historical ownership. In the method 89100, wherein the devicemay include a plurality of modules, each module having correspondingownership data.

With reference to FIG. 90, the method 89100 may further includerestricting access to information about the device from an owner of thedevice 90102. The method 89100 may further include restricting access toinformation about a first owner of the device from a second owner of thedevice 90104. The method 89100 may further include displaying the deviceownership data for the device 90106. The method 89100 may furtherinclude providing updated ownership data to replace the device ownershipdata associated with the device 90108. The method 89100 may furtherinclude providing updated ownership data for one or more modules of thedevice 90110. In the method 89100, the updated ownership data mayinclude a claim of ownership of the device. In the method 89100, eventsresulting in the updated ownership data may include at least one of:creation of the device, sale of the device, decommissioning of thedevice, transfer of ownership of the device, or licensing of the device.The method 89100 may further include comparing the device ownership datato a record of authorized owners 90112, and generating a securitynotification if the device ownership data is not included in the recordof authorized owners 90114. In the method 89100, the database mayinclude a blockchain. The method 89100 may further include certifyingthat the device is not a stolen device 90116. The method 89100 mayfurther include certifying that the device has a fully accountable chainof title 90118. The certification that the device is not a stolen deviceand/or the certification that the device has a fully accountable chainof title may be included in the record or in the device ownership data,or may be provided from elsewhere, e.g., from the IoT device registrar1130 (FIG. 1).

With reference to FIG. 91, the method 89100 may further includeproviding a trust indicator for the device 91102, as disclosed herein.In the method 89100, the trust indicator may include a numeric value. Inthe method 89100, the trust indicator may include an enumerated value.In the method 89100, the trust indicator may be displayed as acolor-coded value. In the method 89100, a value of the trust indicatormay be based at least in part on a location of the device. In the method89100, a value of the trust indicator may be based at least in part on atime period. In the method 89100, a value of the trust indicator may bebased at least in part on one or more of a software version or afirmware version of the device. In the method 89100, determining thetrust indicator may be based at least in part on artificialintelligence. In the method 89100, the trust indicator may be reflectiveof the device being a Greenfield device. In the method 89100, the trustindicator may be reflective of the device being a Brownfield device. Inthe apparatus 120100 (FIG. 120), the trust indicator may be reflectiveof the device being a virtual device, as disclosed herein. Inembodiments, the trust indicator may be reflective of the device being ameta-device, as disclosed herein, e.g., apparatus 120100 (FIG. 120).

In the method 89100, the trust indicator may be displayed as at leastone of: numeric based, color based, symbol based, alphanumeric based,letter based, or any combination thereof. The method 89100 may furtherinclude evaluating an asking price for the device 91104. The evaluatingthe asking price for the device may be based on at least one of: thedevice ownership data, a certification that the device is not a stolendevice, or a certification that the device has a fully accountable chainof title. The method 89100 may further include evaluating an askingprice for a group of devices 91106, which may be based on ownership datafor each device. The method 89100 may further include validating asupply chain 91108. The validating the supply chain may further includedetermining whether modules of the device were sourced from authorizedvendors 91110. The validating the supply chain may further includedetermining whether modules of the device were sourced from fair tradecertified sources 91112. The validation may be based on the deviceownership data, or may be based on data provided from elsewhere, e.g.,from the IoT device registrar 1130 (FIG. 1). The method 89100 mayfurther include providing a carbon rating of the device based on knownratings of sources of modules of the device, which may be determinedbased on the device ownership data 91114. The method 89100 may furtherinclude detecting a device property that indicates a change in ownershipdata 91116. In the method 89100, the device property may include alocation of the device.

FIG. 92 depicts a schematic diagram of an example system 92100 for anIoT device registry, e.g., for network connected devices 1112, 1114,1116, 1118, 1120, 1122, 1124 (FIG. 1), in accordance with an embodimentof the current disclosure. The system 92100 may form part of the server1126 (FIG. 1), e.g., the at least one processor, and/or any otherelectronic computing device described herein.

With reference to FIG. 92, the system 92100 is for an IoT deviceregistry. The system 92100 may include a database 92102, e.g., database1128 (FIG. 1), and a server 92104, e.g., server 1126 (FIG. 1). Thedatabase 92102 may be structured to store records 92106 associating IoTUIDs 92108 with device ownership data 92110. The server 92104 may bestructured to communicate with the database 92102, interpret an IoT UID92108 corresponding to a device, identify, based at least in part on theIoT UID 92108 corresponding to the device, a record 92106 in thedatabase 92102, the record 92106 including device the device ownershipdata 92110 associated with the device, interpret, based at least in parton the record 92106, the device ownership data 92110, and transmit thedevice ownership data 92110.

Certain further aspects of the example system are described herein, anyone or more of which may be present in certain embodiments. In thesystem 92100, the device ownership data 92110 may include a record ofhistorical ownership 92112. In the system 92100, the device may includea plurality of modules, each module having corresponding ownership data.In the system 92100, the server 92104 may be further structured torestrict access to information about the device from an owner of thedevice. In the system 92100, the server 92104 may be further structuredto provide updated ownership data 92114 to replace the device ownershipdata 92110 associated with the device.

FIG. 93 illustrates a flowchart of an example method 93100 fordisplaying IoT device registry data, e.g., for network connected devices1112, 1114, 1116, 1118, 1120, 1122, 1124 (FIG. 1), in accordance with anembodiment of the current disclosure. The method 93100 may be performedby the apparatus 9600 and/or any other computing device describedherein.

The method 93100 may include interpreting, via an input processingcircuit, user input identifying a device ownership query for a device93102. The method further includes generating, via a query provisioningcircuit, a query for an IoT UID, corresponding to the device, to an IoTdevice registrar server 93104. The method further includes identifying,via a record management circuit and based at least in part on the IoTUID, a record in a database at the IoT device registrar server, therecord including device ownership data associated with the device 93106.The method further includes interpreting, via an ownership analysiscircuit and based at least in part on the record, the device ownershipdata 93108. The method further includes transmitting, via an ownershipprovisioning circuit, the device ownership data to a user 93110.

FIG. 94 is another flowchart depicting a method for an IoT deviceregistry display, in accordance with an embodiment of the currentdisclosure. Certain further aspects of the example method are describedherein, any one or more of which may be present in certain embodiments.The features shown in FIGS. 93 and 94 are combinable and interchangeablein any configuration in embodiments. In the method 93100, In the method93100, the device ownership data may include a record of historicalownership. In the method 93100, the device may include a plurality ofmodules, each module having corresponding ownership data. The method93100 may further include restricting access to information about thedevice from an owner of the device. The method 93100 may further includeproviding updated ownership data to replace the device ownership dataassociated with the device.

FIG. 95 depicts a schematic diagram of an example apparatus 95100 for anInternet of Things (IoT) device registry, e.g., for network connecteddevices 1112, 1114, 1116, 1118, 1120, 1122, 1124 (FIG. 1), in accordancewith an embodiment of the current disclosure. The apparatus 95100 mayform part of the server 1126 (FIG. 1), e.g., the at least one processor,and/or any other electronic computing device described herein.

With reference to FIG. 95, the apparatus 95100 is for an IoT deviceregistry. The apparatus 95100 may include an input processing circuit95102, a query provisioning circuit 95104, a record management circuit95106, an ownership analysis circuit 95108, and an ownershipprovisioning circuit 95110. The input processing circuit 95102 may bestructured to interpret user input 95112 identifying a device ownershipquery for a device. The query provisioning circuit 95104 may bestructured to generate a query 95114 for an IoT UID corresponding to thedevice to an IoT device registrar server, e.g., server 1126 (FIG. 1).The record management circuit 95106 may be structured to identify, basedat least in part on the IoT UID, a record 95116 in a database, e.g.,database 1128 (FIG. 1), at the IoT device registrar server, the record95116 including device ownership data 95118 associated with the device.The ownership analysis circuit 95108 may be structured to interpret,based at least in part on the record 95116, the device ownership data95118. The ownership provisioning circuit 95110 may be structured totransmit the device ownership data 95118 to a user. In the apparatus95100, the device ownership data 95118 may include a record ofhistorical ownership 95120. In the apparatus 95100, the device mayinclude a plurality of modules, each module having corresponding deviceownership data 95118. The apparatus 95100 may further include an accessrestriction circuit 95124 structured to restrict access to informationabout the device from an owner of the device. The apparatus 95100 mayfurther include an ownership data update provisioning circuit 95126structured to provide updated ownership data 95128 to replace the deviceownership data 95118 associated with the device.

FIG. 96 depicts a schematic diagram of an example system 96100 for anIoT device registry, e.g., for network connected devices 1112, 1114,1116, 1118, 1120, 1122, 1124 (FIG. 1), in accordance with an embodimentof the current disclosure. The system 96100 may form part of the server1126 (FIG. 1), e.g., the at least one processor, and/or any otherelectronic computing device described herein.

With reference to FIG. 96, the system 96100 is for an IoT deviceregistry. The system 96100 may include an input processing circuit96102, a query provisioning circuit 96104, a database 96106, and aserver 96108. The input processing circuit 96102 may be structured tointerpret user input 96110 identifying a device ownership query for adevice. The query provisioning circuit may be structured to generate aquery 96112 for an IoT UID corresponding to the device. The database maybe structured to store records 96114 associating IoT UIDs 96116 withdevice ownership data 96118. The server 96108 may be structured tocommunicate with the database 96106, interpret the query 96112corresponding to the device, identify an IoT UID 96116 associated withthe device, identify, based at least in part on the IoT UID 96116associated with the device, a record 96114 in the database, the record96114 including the device ownership data 96118 associated with thedevice, interpret, based at least in part on the record 96114, thedevice ownership data 96118, and transmit the device ownership data96118.

Certain further aspects of the example system are described herein, anyone or more of which may be present in certain embodiments. In thesystem 96100, the device ownership data 96118 may include a record ofhistorical ownership 96120. In the system 96100, the device may includea plurality of modules, each module having corresponding ownership data96118. In the system 96100, the server 96108 may be further structuredto restrict access to information about the device from an owner of thedevice. In the system 96100, the server 96108 may be further structuredto provide updated ownership data 96122 to the database to replace thedevice ownership data 96118 associated with the device.

In certain embodiments, the tracking of a chain of title may includeidentification of a trust level, score, and/or rating, which may bedynamic. Certification may be used to evaluate an asking price for adevice, or a group of devices. Embodiments provide for an entity toclaim ownership of a device, which may also relate to device setupand/or provisioning, as disclosed herein. Embodiments may provide forthe detection of device properties, e.g., location, usage profile,network, interface language, device settings, associated telephonenumber, which may be indicative of a change in ownership.

Accordingly, embodiments of the IoT device registry, as disclosedherein, may provide for a trusted source of ownership data relating todevice and/or their modules. Such embodiments may provide for improvedsales and/or marketplaces processes, e.g., by providing for fast andreliable verification of a chain of title for a device and/orindications that a chain of title for a given device may have one ormore discrepancies. Embodiments of the IoT device registry, as disclosedherein, may provide for improved detection of fraud and/or possiblesecurity vulnerabilities by tracking chains of title for devices so thatsuch chains of title can quickly be verified using a trusted source.Embodiments of the IoT device registry, as disclosed herein, may providefor improved billing processes by tracking leased and/or licenseddevices. For example, embodiments of the current disclosure may providefor accurate tracking of an amount of time a device is in the possessionof a party renting and/or leasing the device. Embodiments of the currentdisclosure may also provide for improved shipment tracking as events fora device, e.g., a white good, such as a refrigerator, may be reported tothe IoT device registry, e.g., as event messages, when transfers ofpossession occur and/or when a device is scanned as a checkpoint in adistribution network. Embodiments of the current disclosure may alsoprovide for improved quality of a supply chain by identifying whichentities in the supply chain, who may show up in a chain of title, havelow trust and/or high-risk indictors, as disclosed herein, where theycan be removed and/or replaced with entities having higher trust and/orlower risk indicators. A non-limiting use case of the current disclosureincludes using an IoT device registry, as disclosed herein, to trackshipping containers at a port facility and/or between port facilities.Another non-limiting use case of the current disclosure includes usingan IoT device registry to track ownership of city assets, e.g., watersystem devices, such as pumps, in the event of boundary changes, e.g.,congressional and/or other legislative district boundaries change, partof a county becomes absorbed by a city or vice-versa, and/or portions ofone city are moved to another city.

Embodiments of the current disclosure provide for a method of rating ofInternet of Things (IoT) devices. The rating may be an indicator, e.g.,a score, that relates to a trust indicator (also referred to as atrustworthiness score or trust indicator herein) and/or a risk indicator(also referred to herein as a risk score), associated with a device. Aswill be understood, risk and/or trust indicators may be reciprocals ofeach other, e.g., a device with a low trust score may have a high-riskscore and vice-versa. A risk indicator may reflect a confidence measureassociated with a device. The confidence measure may relate to aconfidence that the device has not been tampered with and/or may reflectthe security of a device. A risk indicator may reflect the potentialrisk that a device may deliberately or inadvertently fail to execute thedesired operation, leak sensitive data when operated, meet contractualobligations, and/or comprise the security of other devices.

In embodiments, the risk indicator may be based on the known history ofthe device, location, predictability of location, predictability ofbehavior, age of the device, and the like. In some case, a riskindicator may reflect the number of operational anomalies in thelifespan of the device. Operational anomalies may reflect operationsoutside of expected operating parameters for a device. Operationalanomalies may include software crashes, physical locations, movement,power consumption, data gaps, error rates, usage statistics,temperatures, and the like.

In embodiments, a risk indicator may include an objective score over alldevices. In some cases, the risk indicator may be normalized or berelative with respect to a class of devices, locations, functions of thedevices, and the like. In one example, more complex devices with morehardware, software components, and connectivity may have a higherobjective risk indicator than simple sensors with one hardware componentand simple wired connectivity. Higher complexity devices may include arelative risk indicator that reflects the relative risk indicator foronly a specific type of high complexity devices. The normalized riskindicator may be a score that ranges between (0) and (100), for examplewith the lowest score assigned to devices with the lowest risk for theparticular class of devices and the highest score assigned to deviceswith the highest risk.

A risk indicator may be dynamic and may change over time as a deviceages, changes locations, is updated with different software andhardware, and the like. A risk indicator may change based on anoperation of a device. A risk indicator may change for differentoperations of a device. For example, a device may be operable to receivedata and provide data to a user. In one example, the operation ofreceiving data by the device may have a higher risk indicator than theoperation of providing data to a user since there may be a risk that thedata that is received by the device may be exposed or leaked.

A risk indicator may be assigned to a new device that is being deployedas well as devices that have already been deployed. Prior to deployment,a Greenfield device may be evaluated and assigned an initial riskindicator. The risk indicator may reflect the complexity of the device,installed software, connectivity, configuration, capabilities ofoperations, and the like. After the device is deployed the riskindicator may be updated based on the location of deployment, operatorof the device, history of operation, predictability of operation, andother metrics described herein. The operation of the device may bemonitored and the operation history may be stored at a registrar serverand used to compute a risk indicator. A deployed device, such as aBrownfield device, may be assigned an initial risk indicator. An initialrisk indicator may be assigned based on an audit of the device hardware,software, location, capabilities, and the like. In many cases, aBrownfield device may be assigned a higher initial risk indicator thanan equivalent Greenfield device since the complete history of theBrownfield device may not be known. The operation of the Brownfielddevice may be monitored and the risk indicator adapted in the samemanner as for the Greenfield device.

In embodiments, operations such as updating or patching software of adevice may decrease the risk indicator of a device. In embodiments, gapswithin the operational record histories of a device may increase therisk indicator of a device. In some embodiments, operators of devicesmay be provided with reports that include data as to what factorscontributed to a particular risk indicator and in some cases operatorsmay be provided with a list of actions for improving (i.e. decreasing)the risk indicator. In some cases, updates and/or modifications todevices to improve the risk indicator may be implemented automatically.Operators of devices may be incentivized to improve the risk indicatorof devices by providing timely and complete histories of devices,updating devices, and the like.

In some embodiments, a risk indicator may be computed as a weighted sumof different scores that reflect aspects of the hardware, software,operation history, location, and the like. The weights and/or functionsfor generating a score may be defined by a user. In some embodiments,weights and functions for computing the risk indicator may be determinedby a trained neural network, artificial intelligence system, and thelike. In some embodiments, a risk indicator may include a plurality ofscores and components that reflect the risk for different functions,components, elements, locations, and the like. The plurality of scorescomprising a risk indicator may be processed according to thepreferences of a user, organization, and the like to determine apersonalized risk indicator.

A risk indicator may be stored in an IoT device registrar server. Theregistrar server may be queried for a risk indicator for a device. Insome cases, a query for a risk indicator may include identifying datafor the device and/or contextual data. Contextual data may includelocation data, time data, type of operation to be executed by thedevice, and the like. When contextual data is provided with the querythe registrar server may return a risk indicator that reflects thecontextual data. When contextual data is provided with a query theweights and functions used to compute the risk indicator may be selectedto reflect the contextual data.

Indicators and/or scores may be converted from one paradigm/entity toanother, in which the IoT device registry may serve as a baseline scoreto which the others can be compared. For example, a first entity, 1136(FIG. 1), e.g., an end user, may have its own scale (a first scale)and/or system for indicating trust and/or risk associated with a device,as disclosed herein, and a second entity 1138 (FIG. 1), e.g., athird-party monitoring service, may use a different scale (a secondscale) and/or system for indicating trust and/or risk associated with adeice. In embodiments, the registrar 1130 (FIG. 1) may have a thirdscale that serves as a baseline to convert values on the first scale tovalues on the second scale or vice-versa. As a non-limiting example, theregistrar 1130 may have a risk scale that rages from zero to one hundred(0-100), the first entity 1136 may have a risk scale that usesenumerated values, e.g., colors such as Green, Blue, Yellow, Orange,Red, and the third-party may have a risk scale that ranges from negative100 to positive 100 (⁻100-⁺100). In embodiments, the first entity 1136and/or the registrar 1130 may store a first mapping from the first scaleto the second scale, e.g., green may equate to (0-19), blue may equateto (20-39), yellow may equate to (40-59), orange may equate to (60-79),and red may equate to (80-100). The second entity 1138 and/or theregistrar 1130 may store a second mapping that maps the second scale tothe third scale, e.g., (⁻100-0) may equate to (0-30), (⁺1-⁺80) mayequate to (31-60), and (⁺81-⁺100) may equate to (61-100). Thus, a riskscore of (85) reported by the second entity 1138, e.g., a third-partymonitor, may be translated using the registrar's 1130 scale to the firstentity's 1136 scale where it is displayed to the first entity 1136 as anorange value, e.g., moderate to high risk. As will be understood, suchconversion between different trust and/or risk scales may beincorporated into the embodiments disclosed herein with respect to themetaverse and augmented reality applications as disclosed herein. Forexample, a child profile metaverse account may have a different riskand/or trust scale as compared to an adult profile, e.g., the child'sscale may be weighted to favor caution higher than the adult profile. Inembodiments, an entity 1136 may use different risk and/or trust scalefor different external entities, e.g., 1138 and/or 1134, that it mayinteract with and/or receive devices from. For example, a corporate user1136 may have a first scale weighted towards trusting a device, wherethe first scale may be for use with a trusted party, and a second scaleweighted towards not trusting a device, where the second scale may befor use with unknown and/or untrusted parties.

In embodiments, risk indicators and other trust indicators may beprovided for online servers to include game/metaverse servers.Embodiments may provide for augmented reality (AR) trust indicators andrisk indicators to be shown in relation to devices. For example,automatic teller machines (ATM) and/or card readers may be identifiedand the risk indicator for the devices may be queried from theregistrars. Augmented reality interfaces may provide a display such asan overlay that identifies the risk indicator and/or the trust indicatorfor the ATM. The augmented reality may include color codes to show therelative risk or trust associated with the ATM. In some embodiments, aquery may include contextual data. For example, continuing with the ATMexample, contextual data may include the location (such as GPS locationdata) of the ATM, the transaction type that the user wishes to use theATM for, and a picture or a video of the ATM. The contextual data may beused to further customize or personalize the risk indicator and trustindicators. For example, the pictures and video of the ATM may becompared to stored pictures and video of the ATM and the risk indicatormay be adjusted if the new pictures or video show differences to ahistorical image of the ATM.

Referring again to FIGS. 1 and 2, embodiments of the current disclosuremay provide for the generation of a risk indicator by a registrationserver 1126, and/or a computing device operated by a manufacturer 1134,end user 1136, third party 1138, and/or other entities. Generation of arisk and/or trust indicator, as disclosed herein, may form part of themonitor and secure component 2114 (FIG. 2), including the set servicealerts subcomponent 2134 (FIG. 2). In embodiments, the process ofgenerating risk and/or trust indicators may be presale or post-sale withrespect to a device. Presale determination of a risk indicator may occurprior to the release of the Greenfield device from a manufacturer, forexample, an original equipment manufacturer (OEM), for use by end users.Post-sale determination of a risk indicator may occur when an end useridentifies a Brownfield device for risk assessment and/or encounters aGreenfield device that has been and/or is in service after having beeninitially purchased. In embodiments, a device's risk and/or trustindicator may change over time, e.g., a device's risk and/or trust scoremay improve over time as more of its history becomes tracked in theregistry 1129 (FIG. 1), via event messages 6116 (FIG. 6). Certainevents, e.g., taking a patch, may also improve a device's trust and/orrisk score, whereas other events, e.g., missing a patch and/or beingreported as stolen and/or compromised, may decreases a device's trustand/or risk score.

Turning to FIG. 97, a method 97100 for transmitting a risk indicator isshown. The method 97100 may be performed by a manufacturer 1134 (FIG.1), e.g., a module manufacturer and/or a manufacturer of a device thatincludes one or more modules. The method 97100, in embodiments, may alsobe performed by a user 1136 and/or third party 1138 (FIG. 1). The method97100 includes interpreting, via an Internet of Things UniversalIdentifier (IoT UID) processing circuit, an IoT UID corresponding to adevice 97102. The method 97100 may include identifying, via a recordmanagement circuit and based at least in part on the IoT UID, a recordin a database corresponding to the device 97104 and determining, via atrust analysis circuit and based at least in part on the record, a riskindicator of the device 97106. The method may further includetransmitting, via an indicator provisioning circuit, the risk indicator97108.

Referring to FIG. 98, an apparatus 98100 that may be configured totransmit a risk indicator may include an Internet of Things UniversalIdentifier (IoT UID) processing circuit 98102 that is structured tointerpret an IoT UID 6118 corresponding to a device. The apparatus 98100may further include a record management circuit 98104 structured toidentify, based at least in part on the IoT UID 6118, a record 1152(FIG. 1) in a database 1128 (FIG. 1) corresponding to the device and atrust analysis circuit 98106 structured to determine, based at least inpart on the record 1152, a risk indicator of the device. The apparatus98100 may further include an indicator provisioning circuit 98108structured to transmit the risk indicator.

Turning to FIG. 99, a method 99100 for interpreting a trust indicator isshown. The method 99100 includes interpreting, via an Internet of ThingsUniversal Identifier (IoT UID) processing circuit, an IoT UIDcorresponding to a device 99102. The method 99100 may includegenerating, via a trust verification circuit, a trust indicator requestvalue that includes the IoT UID corresponding to the device 99104 andtransmitting, via a trust indicator request provisioning circuit, thetrust indicator request value to an IoT device registrar server 99106.The method 99100 may further include interpreting, via a trust indicatorprocessing circuit, a trust indicator generated by the IoT deviceregistrar server in response to the trust indicator request value 99108.

Referring to FIG. 100, an apparatus 100100 that may be configured totransmit a risk indicator may include an Internet of Things UniversalIdentifier (IoT UID) processing circuit 100102 that is structured tointerpret an IoT UID corresponding to a device. The apparatus 100100 mayfurther include a trust verification circuit 100104 structured togenerate a trust indicator request value that includes the IoT UIDcorresponding to the device and a trust indicator request provisioningcircuit 100106 structured to transmit the trust indicator request valueto an IoT device registrar server. The apparatus 100100 may furtherinclude a trust indicator processing circuit 100108 structured tointerpret a trust indicator generated by the IoT device registrar serverin response to the trust indicator request value.

Embodiments may provide for risk and/or trust scores/indicators and/orcertification of devices, e.g., servers and/or other physical assets,supporting metaverse activities, and/or devices appearing and/orexisting within the metaverse. Devices in the metaverse may be virtualdevices, e.g., objects in the metaverse having real-world counterparts(real-world devices), where the virtual device is a digital-twin of thereal-world counterpart. Non-limiting examples of virtual devicesinclude: vehicles; rooms; buildings; controllers (thermostats, securitysystem key pads, process logic controllers, and the like); sensors(temperature, pressure, voltage, amperage, magnetic fields, weatherconditions, and the like); and/or other types of devices where havingboth real-world and metaverse versions of the devices provides abenefit. A digital virtual device may have properties corresponding toits real-world counterpart that may be updated in real-time and/or on aperiodic basis. In embodiments, a digital twin may be updated withpredicted properties for its real-world counterpart in the event thereal-world counterpart is unable to communicate with an IoT deviceregistry to which the real-world counterpart and/or its digital twin maybe registered with, as described herein. Devices in the metaverse may bereal-world devices, e.g., objects in the real-world having metaversecounterparts (digital twin virtual devices) and/or supporting metaverseactivities. Non-limiting examples of real-world devices include servershosting metaverse rooms, servers hosting webstores from which an avatarcan purchase goods or services; user devices used to access a metaverse;and/or counterparts to virtual devices, as described herein. Devices inthe metaverse may be meta-devices, e.g., objects in the metaverselacking real-world counterparts. In embodiments, a device may havemodules that are virtual devices and modules that are meta-devices. Inembodiments, an IoT device registry may provide for registration ofvirtual devices, real-world devices, and/or meta-devices, as disclosedherein, and/or the services and/or functions associated withregistration for registered virtual devices, real-world devices, and/ormeta-devices, as also disclosed herein.

A risk score/indictor may be a measure of the risk of taking aparticular action (or set of actions) and/or interacting with a deviceand/or a set of devices. A trust score/indictor may be a measure oftrust of a device as disclosed herein. A risk score may equate to atrust score, e.g., high risk equals a low trust score and vice-versa. Inembodiments, a scale for a risk score may be user adjustable in relationto a base risk score scale maintained by an IoT device registrar. Forexample, a user with a low risk tolerance may see objects with red riskwarnings that other users with higher risk tolerances may see with greencheckmarks. Conversely, a user with a high risk tolerance may seeobjects with green checkmarks that other users with lower risktolerances may see with red risk warnings. In embodiments, a user's riskscore scale may be defined by the user, another use, and/orinferred/predicted via artificial intelligence based at least in part onone or more characteristics of the user, e.g., age, sex, location,medical condition, etc., and/or by analyzing their actions within themetaverse. In such embodiments, the artificial intelligence may adjustthe user's risk score scale as the user spends an increasing amount oftime in the metaverse and gains “metaverse street smarts”.

As a non-limiting example, a user in the metaverse may be provided witha risk and/or trust score/indicator of a server (retrieved/queried froman IoT device registrar using the server's IoT UID) before entering anarea, e.g., a room, in the metaverse hosted by that server. Embodimentsmay provide for risk and/or trust scores/indicators of users, aplurality of users, and the like, within the metaverse (that have IoTUIDs registered with an IoT device registrar), such as in an area that auser is about to enter or interact with. Such risk and/or trust scoresmay be based on the risk and/or trust score of devices associated withthe user that are also registered with the IoT device registrar. Forexample, embodiments may assign a risk score of red (high risk) to anavatar having an IoT UID corresponding to a user associated withfraudulent activities and/or devices registered in an IoT deviceregistry 1129 (FIG. 1), as disclosed herein. Embodiments maydepict/express the risk scores within the metaverse based on one or moreof color, numerical value, sound, and/or any combination thereof.Embodiments of the disclosure may provide for an end user applicationthat restricts a user from accessing or interacting with devices in themetaverse having IoT UIDs associated with a high risk and/or low trustlevel, for example, a server, an area, an object, an avatar, or anotheruser, that does not meet a minimum risk and/or trust threshold and/ordoes not present a certification from an IoT device registrar.Embodiments of the application may be a parental control software agent.The risk and/or trust scores/indicators may be determined, stored,and/or maintained by an IoT UID device registrar, e.g., in an IoT deviceregistrar server 1126 and/or database 1128 (FIG. 1), in association withIoT UIDs.

The device in the metaverse may be an area of the metaverse, such as aroom, a building, an outside environment, and the like. As the usermoves through the metaverse a trust indicator may be determined for thedevice in the metaverse, where for instance, a trust indicator istransmitted to a user before the user enters an area of the metaverseassociated with the device, e.g., a room, an object within a room, anavatar, etc. The trust indicator of the device in the metaverse may bebased at least in part on a combination of trust indicators of aplurality of devices associated with the device, e.g., an avatarassociated with five (5) devices where four (4) devices have high trustscores and one (1) device has a medium trust score may be assigned ahigh trust level, whereas the same avatar associated with five (5)devices where four (4) have medium trust scores and one (1) has a hightrust score may receive a medium trust score. The trust indicator of thedevice may be based at least in part on a combination of trustindicators of a plurality of modules associated with the device. Thetrust indicator may be updated based on interactions with the device,e.g., an device unfamiliar to the IoT UID registry and/or a user usingthe IoT UID registry may initially receive a low trust/high risk score,where additional interactions with the device (without incident) mayraise the trust score/lower the risk score of the device. Inembodiments, trust and/or risk scores may be tailored to a particularuser/entity using the IoT UID device. For example, a device may beunfamiliar to a first user and receive a low trust/high risk score withrespect to the first user. The same device, however, may be familiar toa second user and receive a high trust/low risk score with respect tothe second user.

The trust and/or risk indicator may be a numeric value, an enumeratedvalue, and the like. The trust and/or risk indicator may be displayed,such as a value, a color-coded value, a graphic display of a value, andthe like. The trust and/or risk indicator may include a trust/risklevel, a trust/risk score, a trust/risk rating, and the like. The trustand/or risk indicator may be based at least in part on a location of thedevice, a time period, a software and/or firmware version of the device,a trust and/or risk indicator of other devices associated with thedevice, a trust and/or risk indicator of a user associated with thedevice, and the like. For example, an avatar representing a kids'cartoon character may have a lower trust rating in a metaverse room whena local time is between midnight and 4:00 am than the avatar would havein the same room between 9:00 am to 5:00 pm. As another example, anobject appearing in the metaverse outside of a known schedule for theobject may receive a lower score than the object has during itsscheduled times. The determining of the trust and/or risk indicator maybe based at least in part on artificial intelligence. The trust and/orrisk indicator may be reflective of the device being a Greenfield deviceor a Brownfield device, as disclosed herein.

In certain aspects, an interaction may be authorized or prohibited witha device based at least in part on the trust and/or risk indicator, suchas where the interaction is an exchange of data with the device,establishing a network connection with the device, and the like. Inembodiments, the trust and/or risk indicator may be based on an event ofthe device, such as a transfer of ownership, a patching of the device,an updating of software or firmware of the device, and the like.

Referring to FIG. 101, a method 101100 may be provided. The method101100 may include interpreting 101102, via an Internet of Things (IoT)Universal Identification (UID) processing circuit, an IoT UIDcorresponding to a device in a metaverse; identifying 101104, via arecord management circuit and based at least in part on the IoT UID, arecord in a database corresponding to the device in the metaverse;determining 101106, via a trust analysis circuit and based at least inpart on the record, a trust indicator of the device in the metaverse;and transmitting 101108, via a trust indicator provisioning circuit, thetrust indicator.

Referring to FIG. 102, an apparatus 102100 for an IoT UID 102110 may beprovided. The apparatus 102100 may include a IoT UID processing circuit102102, a record management circuit 102104, a trust analysis circuit102106, a trust indicator provisioning circuit 102108, and the like. TheIoT UID processing circuit 102102 may be structured to interpret an IoTUID 102110 corresponding to a device in a metaverse. The recordmanagement circuit 102104 may be structured to identify, based at leastin part on the IoT UID 102110, a record 102112 in a databasecorresponding to the device in the metaverse. The trust analysis circuit102106 may be structured to determine, based at least in part on therecord 102112, a trust indicator 102114 of the device in the metaverse.The trust indicator provisioning circuit 102108 may be structured totransmit 102116 the trust indicator.

Referring to FIG. 103, a method 103100 may be provided. The method103100 may include interpreting 103102, via an IoT UID processingcircuit, an IoT UID corresponding to a device in a metaverse; generating103104, via a trust verification circuit, a trust indicator requestvalue that includes the IoT UID corresponding to the device in themetaverse; transmitting 103106, via a trust indicator requestprovisioning circuit, a trust indicator request to an IoT deviceregistrar server 1126; and interpreting 103108, via a trust indicatorprocessing circuit, a trust indicator generated by the IoT deviceregistrar server 1126 in response to the trust indicator request.

Referring to FIG. 104, an apparatus 104100 for an IoT UID 104110 may beprovided. The apparatus 104100 may include an IoT UID processing circuit104102, a trust verification circuit 104104, a trust indicator requestprovisioning circuit 104106, a trust indicator processing circuit104108, and the like. The IoT UID processing circuit 104102 may bestructured to interpret an IoT UID 104110 corresponding to a device in ametaverse. The trust verification circuit 104104 may be structured togenerate a trust indicator request value 104112 that includes the IoTUID 104110 corresponding to the device in the metaverse. The trustindicator request provisioning circuit 104106 may be structured totransmit a trust indicator request 104114 to an IoT device registrarserver 1126. The trust indicator processing circuit 104108 may bestructured to interpret a trust indicator 104116 generated by the IoTdevice registrar server 1126 in response to the trust indicator request.

In a non-limiting example, a user in the metaverse may approach a roomoperated by a server. The server may be registered with an IoT deviceregistry, as disclosed herein, such that the user can query the serverfor its IoT UID and then query the IoT device registry to retrieve thesecurity and/or risk indicator of the server. In another non-limitingexample, the server may present the user with a trust and/or riskindictor with an encryption-based certificate from the IoT deviceregistrar. In another non-limiting example, a user may encounter ameta-device, e.g., a jet fighter plane, where a risk score may bedepicted above the jet fighter plane such that the user can see andaccept the risk, e.g., a cyber security risk, of interacting with thejet, i.e., flying it in the metaverse. The risk score may be based atleast in part on the manufacturer/software company who programmed thejet fighter for the metaverse. In another non-limiting example, a usermay interact with a virtual home security keypad in the metaverse, wherethe user may be accessing the metaverse from a location other than theirhome, where the virtual security keypad is a digital twin of a securitykeypad in the user's house and can control a corresponding securitysystem for the user's home. If the virtual security keypad and itsreal-word counterpart are registered with an IoT device registry, asdescribed herein, the user can verify that the virtual security keypadis authenticate and not a spoofed object made by a malicious actor.

Embodiments may provide for the depiction and use of risk and/or riskscores/indicators, as disclosed herein, and/or certification viaaugmented reality (AR). Embodiments may depict risk scores of objectsencountered by a user. As a non-limiting example, a user wearing an ARdevice, such as an AR headset, AR contact lenses, AR glasses, or ARgoggles, may see an automated teller machine (ATM) (in the real-world)associated with a green indicator, e.g., an AR object overlaid on theATM, if the device has a sufficiently high trust indicator, e.g., trustscore/rating/level value, or red if the device has a sufficiently lowtrust indicator. Embodiments may depict trust indicators for individualsbased on the trust indicators of devices associated with the scoredindividuals.

In embodiments, the device in the AR may be an IoT device, a server, auser, an avatar, and the like. A device in the AR may correspond to anarea of a metaverse, such as where the area in the metaverse is a room,a structure, an outside environment, and the like, in the metaverse. Thedevice in the AR may be a virtual device, a real-world device, or ameta-device, as disclosed herein.

In certain aspects, a trust and/or risk indicator of the device in theAR may be determined, such as where the trust indicator has a numericvalue, an enumerated value, and the like. In embodiments, the trustand/or risk indicator may be displayed via an AR device, such as inassociation with a real-world device, overlaid on a real-world device,and the like. The AR device may be an AR headset, AR contact lenses, ARglasses, AR goggles, and the like. In embodiments, the trust and/or riskindicator may be displayed as a color-coded value. The trust and/or riskindicator may be based at least in part on a location of the device, atime period, a software and/or firmware version of the device, a trustand/or risk indicator of a device associated with the device, a trustand/or risk indicator of a user associated with the device, and thelike, as disclosed herein. The trust and/or risk indicator may bereflective of the device being a Greenfield device or Brownfield device.In embodiments, the trust and/or risk indicator may be reflective of thedevice being a virtual device, a real-world device, and/or ameta-device, as disclosed herein. Determining the trust and/or riskindicator may be based at least in part on artificial intelligence, asdisclosed herein.

In embodiments, a trust and/or risk indicator may be provided to a useras they interact (or attempt to interact) with a device. An interactionwith a device may be authorized, prohibited, cautioned, and the like,based at least in part on the trust and/or risk indicator, such as, forinstance, the interaction is an exchange of data with a device,establishing a network connection with the device, and the like. A trustand/or risk indicator of a device in the AR may be based at least inpart on a combination of trust and/or risk indicators of a plurality ofentities in the AR. A trust and/or risk indicator of the device may beprovided to a user before the user enters an area of a metaverse and/orthe real world containing the device. A trust and/or risk indicator ofthe device may be based at least in part on a combination of trustand/or risk indicators of a plurality of modules associated with thedevice. The trust and/or risk indicator may be updated based on aninteraction with the device, as disclosed herein.

In certain aspects, the trust and/or risk indicator may be adjustedbased on an event of the device, such as where the event is a transferof ownership, a patching of the device, and the like. The event may bean updating at least one of software or firmware of the device. Methodsand systems may include a parental control software agent.

Referring to FIG. 105, a method 105100 may be provided. The method105100 may include interpreting 105102, via an Internet of Things (IoT)Universal Identification (UID) processing circuit, an IoT UIDcorresponding to a device in an augmented reality (AR); identifying105104, via a record management circuit and based at least in part onthe IoT UID, a record in a database corresponding to the device in theAR; determining 105106, via a trust analysis circuit and based at leastin part on the record, a trust indicator of the device in the AR; andtransmitting 105108, via a trust indicator provisioning circuit, thetrust indicator.

Referring to FIG. 106, an apparatus 106100 for an IoT UID is provided.The apparatus 106100 may include an IoT UID processing circuit 106102, arecord management circuit 106104, a trust analysis circuit 106106, atrust indicator provisioning circuit 106108, and the like. The IoT UIDprocessing circuit 106102 may be structured to interpret an IoT UID106110 corresponding to a device in an augmented reality (AR). Therecord management circuit 106104 may be structured to identify, based atleast in part on the IoT UID, a record 106112 in a databasecorresponding to the device in the AR. The trust analysis circuit 106106may be structured to determine, based at least in part on the record, atrust indicator 106114 of the device in the AR. The trust indicatorprovisioning circuit 106108 may be structured to transmit 106116 thetrust indicator.

Referring to FIG. 107, a method 107100 may be provided. The method107100 may include interpreting 107102, via an Internet of Things (IoT)Universal Identification (UID) processing circuit, an IoT UIDcorresponding to a device in an augmented reality (AR); generating107104, via a trust verification circuit, a trust indicator requestvalue that includes the IoT UID corresponding to the device in the AR;transmitting 107106, via a trust indicator request provisioning circuit,a trust indicator request to an IoT device registrar server; andinterpreting 107108, via a trust indicator processing circuit, a trustindicator generated by the IoT device registrar server 1126 (FIG. 1) inresponse to the trust indicator request.

Referring to FIG. 108, an apparatus 108100 for an IoT UID is provided.The apparatus 108100 may include an IoT UID processing circuit 108102,trust verification circuit 108104, trust indicator request provisioningcircuit 108106, a trust indicator processing circuit 108108, and thelike. The IoT UID processing circuit 108102 may be structured tointerpret an IoT UID 108110 corresponding to a device in an augmentedreality (AR). The trust verification circuit 108104 may be structured togenerate a trust indicator request value 108112 that includes the IoTUID corresponding to the device in the AR. The trust indicator requestprovisioning circuit 108106 may be structured to transmit a trustindicator request 108114 to an IoT device registrar server 1126 (FIG.1). The trust indicator processing circuit 108108 may be structured tointerpret a trust indicator 108116 generated by the IoT device registrarserver in response to the trust indicator request.

A non-limiting use case may be scenario where a user wearing an ARheadset enters a convenience store to purchase a bottle of water. Theuser may proceed to the checkout counter with the bottle such that apayment device, e.g., debit card reader, is visible within the field ofview of the AR headset. If the payment device is registered with an IoTdevice registry, as disclosed herein, the AR headset may query the IoTdevice registry for a trust and/or risk identifier for the paymentdevice and depict a visualization of the trust and/or risk identifier inrelation to the payment device, e.g., on, above, below, etc., thepayment device. For example, if the payment device is registered and hashad no known instances of fraudulent transactions, the AR headset mayshow a green checkmark above the payment device. In the event thepayment device is not registered with the IoT device registry or hasbeen associated with one or more fraudulent transactions, the AR headsetmay depict a red ‘X’ above the payment device. In embodiments,visualization of the trust and/or risk score indicator in AR may be acolorization and/or shading of a real-world object, e.g., shading thepayment device green if safe to use or red is potentially unsafe to use.Embodiments may also use such visualizations for stores that are withinthe metaverse, e.g., a virtual convenience store selling metaverseobjects and/or services, such as in-game app purchases.

Embodiments may include an agent that monitors devices having IoT UIDs6118 (FIG. 6) registered with an IoT device registry 1129 (FIG. 1), asdisclosed herein, for known vulnerabilities and/or unusual activitiesand provides alerts and/or access to remedial measures, e.g., patches.The agents/sentries and/or corresponding apparatuses and/or methodsdisclosed herein may provide for alert management, e.g., the setting andtriggering of alerts based on conditional logic. For example, the ownerand/or operators of a device may set alerts configured to notify theowner and/or operator of unusual activity associated with one or morenetwork connected devices. Non-limiting examples of such unusualactivity may be an unanticipated hardware, software, and/or firmwarechange, e.g., an unexpected addition of a new network access point in adevice; and/or unexpected ownership changes and/or attempted ownershipchanges. Embodiments of the current disclosure may also provide foranalytical analysis of data corresponding to the network connecteddevices, e.g., usage and/or trend data, risk management data, datacompliance management, etc. Non-limiting examples of trends may includedetecting that a particular type of device across multiple users and/ororganizations has recurring battery issues and/or other types ofhardware malfunctions; detecting that devices associated with aparticular organization are being replaced and/or retired at a higherthan expected rate; detecting that devices associated with a particularorganization are, on average, behind in scheduled patching as comparedto other organizations; and/or the like.

Such analysis may be performed by the registration server, and/or anagent/sentry executing on one or more of the computing devices disclosedherein, on data, e.g., device property data, retrieved from theplurality of records within the IoT device registry. Risk analysis maybe based at least in part on the attributes of one or more devices,e.g., lifecycle events reflected by changes of a device's attributes,e.g., device property data, as recorded in its corresponding record 6110(FIG. 6) in the IoT device registry 1129 (FIG. 1).

Embodiments of the agent/sentry and/or corresponding apparatuses and/ormethod, disclosed herein, may form part of the monitor and securecomponent 2114 (FIG. 2), including subcomponents 2132, and/or 2134; themanage lifecycle component 2110 (FIG. 2), including subcomponent 2120;and/or the analytics component 2112, including subcomponents 2126 and/or2128. The agent/sentry may execute on the same system as the IoT deviceregistry and/or on a system owned and/or operated by an end user 1136(FIG. 1), manufacturer 1134 (FIG. 1), e.g., an original equipmentmanufacturer (OEM), third party monitor 1138 (FIG. 1), and/or a devicemanagement platform. Embodiments may provide for the collection ofremedial measures from a device manufacturer and/or other source, e.g.,the National Security Agency (NSA), Linux Distros, Microsoft, Apple,Google, etc., and may provide the generation of campaigns to manageand/or track implementing the remedial action of a plurality of affecteddevices, e.g., devices affected by a “software Bill of Materials (SBoM)”and/or “Cybersecurity Bill of materials (CBoM)”. For example, where anembodiment of the agent/sentry detects a change in a device's propertydata, e.g., a configuration change, in a record 6110 in an IoT deviceregistry 1129, as disclosed herein, the agent/sentry may poll anexternal database to retrieve a patch, a link to the patch, and/orwritten instructions for implementing the patch. The agent/sentry maythen transmit the same to an SPG, as disclosed herein, forexecution/implementation by an administrator of the affected device.Embodiments may provide for the aggregation of hardware and/or softwareversion data which the agent may use to detect vulnerabilities.Embodiments may access a vulnerability database. Embodiments maygenerate a vulnerability database. The sentry may send an alert when itdetects a configuration change of a module, e.g., a new networkinterface controller (NIC) has been installed.

In embodiments, a SPG may depict one or more metrics related to acampaign, e.g., a patching campaign, such as devices patches vs devicesyet to be patched. In embodiments, an entity having a high number and/orpercentage, e.g., greater-than 80%, of patched devices may have a highertrust/lower risk score/indicator as compared to an entity which has alow number and/or percentage, e.g., less-than 20%, of patched devices.The SPG may also depict the locations and/or scheduled patch time(s) forone or more devices included within a campaign. In embodiments, the SPGmay be structured to manage a campaign on behalf of a manufacturer 1134,end user 1136, and/or a third-party service provider 1138. Inembodiments, the SPG may provide a link to a patch, and/or writteninstructions for the patch, for a corresponding campaign. Thus, as willbe appreciated, embodiments of the current disclosure may provide for asuccinct graphical user interface (GUI) from which an entity can managea campaign for a plurality of devices having IoT UIDs 6118 registeredwith an IoT device registry 1129, as compared to traditional systems.Further, registration of devices with an IoT device registry 1129, asdisclosed herein, provides for a manufacturer 1134 of the devices,and/or third-party monitoring service 1138 charged with managing thedevices, to manage patching and/or campaigns involving the devices eventhough the devices may be owned by different end users 1136 and/orchange ownership, which could occur during a campaign.

Referring to FIG. 109, a method 109100 may be provided. The method mayinclude monitoring 109102, via at least one processor, one or morerecords 1131 (FIG. 1), 6110 (FIG. 6) in an internet of things (IoT)device registry 1129 (FIG. 1) for changes in device property data 6120(FIG. 6) corresponding to one or more devices, e.g., 1112, 1114, 1116,and/or 1118 (FIG. 1), each corresponding to one of the one or morerecords. The method 109100 may further include detecting 109104, via theat least one processor, a change in the device property data of at leastone record; determining 109106, via the at least one processor, that thechange corresponds to a security vulnerability, an event, and/or othertype of change in device property data, as disclosed herein; andgenerating 109108, via at least one processor and responsive to thedetermined security vulnerability, a message that identifies a devicecorresponding to the change in the device property data. The method109100 may further include transmitting 109110, via the at least oneprocessor, the message. Non-limiting examples of detected changes mayinclude software and/or firmware version updates, location changes,ownership changes, connectivity changes, and/or any change between avalue of the device property data 6120 (FIG. 6) currently in a record1131 and a historical value for the same device property data.Embodiments may use a change field/flag in a record 1131 to reduce thenumber of records that need to be retrieved/returned in a query as partof the monitoring 109102. For example, a record 1131 may include achange field/flag that may be set when a record 1131 is updated, e.g.,by an event message 6116, and reset after the record 1131 is retrievedand/or read as part of the monitoring 109102. Embodiments of the currentdisclosure may also keep a copy of the previous value of a field in therecord after being updated in response to an event message 6116, asdisclosed herein. As such, determining 109106 the change may includecomparing the previous value of a field in a record 1131 to the currentvalue.

In embodiments, the message may be displayed, e.g., on a SPG, and/or ona device corresponding to the IoT UID in the record 1131. Changes in thedevice property data may be logged in a database and/or another systemfor tracking a device's history, e.g., a block chain, as disclosedherein. In embodiments, the message may be received at a devicemanagement platform, which in turn, may trigger quarantining and/orpatching the device, such as where the message is an alert. A trustindicator, as disclosed herein, may be adjusted based at least in parton the change, such as where the trust indicator is a trust score, arating, a level value, and the like. The adjusting may increase when thechange corresponds to a patching and/or an updating of software and/orfirmware of the device. The adjusting may decrease when the changecorresponds to a vulnerability, and the like. For example, whereownership of the device has passed to an entity associated with one ormore IoT UIDs of devices registered in an IoT device registry 1129having low trust and/or high-risk scores. The change may correspond toan addition of a new module into the device. For example, installing anadditional network card into a device may increase a risk score of thedevice as the additional network card increases the number of accesspoints of the device. Conversely, removing a network card from a devicemay lower the risk score of the device as doing so removes an accesspoint of the device. The new module may be an input/output device, wherethe input/output device is a network interface device, a media device,and the like. The change may correspond to a change in ownership of thedevice, a location of the device, and the like. The securityvulnerability may be based on a software and/or firmware of the device,on a hardware version of the device, and the like. A securityvulnerabilities database may be accessed to pull security vulnerabilitysignatures to determine if a registered device is affected.

In embodiments, the agent may raise an alert when the age of a moduleand/or device, as determined by analyzing the records 1131 in the IoTUID registry 1129, increases, e.g., an embedded computer on a vehiclehaving an operating system that has gone more than two (2) years withoutan update may pose a security risk.

Referring to FIG. 110, a method 110100 is provided. The method mayinclude interpreting at a first time 110102, via a device property dataprocessing circuit, device property data corresponding to a deviceregistered with an IoT device registry. The method 110100 may furtherinclude interpreting at a second time 110104, via the device propertydata processing circuit, the device property data corresponding to thedevice registered with the IoT device registry, and detecting 110106,via a change detection circuit, a change in the device property databetween the first time and the second time. The method 110100 mayfurther include generating 110108, via an alert circuit and responsiveto detecting the change, a message that identifies the devicecorresponding to the device property data; and transmitting 110110, viaan alert provisioning circuit, the message. In embodiments, the messagemay include the IoT UID of the affected device.

Referring to FIG. 111, an apparatus 111100 is provided. The apparatus111100 may include a device property data processing circuit 111102, achange detection circuit 111104, an alert circuit 111106, and an alertprovisioning circuit 111108. The device property data processing circuitis structured to at a first time, interpret, device property data 111110corresponding to a device registered with an IoT device registry, and ata second time, interpret, the device property data 111110 correspondingto the device registered with the IoT device registry. The changedetection circuit is structured to detect a change 111112 in the deviceproperty data between the first time and the second time. The alertcircuit is structured to generate, responsive to the detected change, amessage 111114 that identifies the device corresponding to the deviceproperty data. The alert provisioning circuit is structured to transmit111116 the message.

Referring to FIG. 112, a system 112100 is provided. The system mayinclude a device management platform 112102 and a sentry device 112104.The device management platform 112102 may be structured to manage one ormore devices registered with an IoT device registry, and the sentrydevice 112104 may be structured to monitor 112106 the IoT deviceregistry for changes in property data corresponding to the registeredone or more devices. The sentry device 112104 may be further structuredto detect 112108 a change in the property data for at least one of theone or more devices, and to determine 112110 that the detected changecorresponds to a security vulnerability. The sentry device 112104 may befurther structured to generate 112112, responsive to the determinedsecurity vulnerability, a message that identifies the at least onedevice of the one or more devices; and transmit 112114 the message tothe device management platform. The device management platform may befurther structured to interpret the message transmitted by the sentrydevice, and quarantine 112116 the at least one device, patch 112118 theat least one device, and the like.

Referring to FIG. 113, a method 113100 is provided. The method mayinclude interpreting 113102, via a device property data processingcircuit, device property data corresponding to a device registered withan IoT device registry; detecting 113104, via a security analysiscircuit, based at least in part on the device property data, that thedevice is subject to a security vulnerability; and generating 113106,responsive to the detected security vulnerability, via an alert circuit,a message that identifies the device. The method 113100 may furtherinclude transmitting 113108, via an alert provisioning circuit, themessage.

Referring to FIG. 114, an apparatus 11400 is provided. The apparatus mayinclude a device property data processing circuit 11402, a securityanalysis circuit 11404, an alert circuit 11406, and an alertprovisioning circuit 11408. The device property data processing circuit11402 may be structured to interpret 11410 device property datacorresponding to a device registered with an IoT device registry. Thesecurity analysis circuit 11404 may be structured to determine 11412,based at least in part on the device property data, that the device issubject to a security vulnerability. The alert circuit 11406 may bestructured to generate, responsive to the determined securityvulnerability, a message 11414 that identifies the device. The alertprovisioning circuit 11408 may be structured to transmit 11416 themessage.

Referring again to FIGS. 1 and 2, embodiments of the current disclosuremay provide for detection of down devices via detecting outage patternsin device property data 6120 data of records 6110 (FIG. 6) forregistered devices corresponding to IoT UIDs 6118, as disclosed herein.A down device, also referred to herein as a downed device, missingdevice, disconnected device, off device, malfunctioning device, brokendevice, and/or the like, may be a device, e.g., 1112, 1114, 1116, 1118,1120, 1122, and/or 1124 (FIG. 1), that is experiencing, has experienced,and/or is likely to experience an outage. Non-limiting examples ofoutages may be related to and/or the result of: communication issues,e.g., rain, solar flares, weather events, etc., poor reception and/ortransmission due to structures, e.g., buildings, tree leaves, etc.,cyber-attacks, malfunctioning network components, e.g., routers, towers,relays, fiber and/or coaxial lines, DNS servers, etc.; power issues,e.g., low battery power, no battery power, excessive battery power;sensor issues, e.g., temperature, pressure, voltage, conductivity,amperage, etc.; user input device malfunctions, e.g., broken touchscreens, broken keyboards, broken mice; and/or other types ofabnormalities. In embodiments, apparatus and/or processes that providefor the detection of down devices, as disclosed herein, may form part ofthe registry 1129, e.g., the usage and trend analysis subcomponent 2130,the detect unusual behavior subcomponent 2132, and/or a set servicealerts subcomponent 2134. In embodiments, the devices and/or processesthat provide for the detection of down devices, as disclosed herein, mayform part of a device management platform operated by a manufacturer1134, an end user 1136, and/or a third party 1138. Embodiments of thecurrent disclosure may provide for an agent that executes on one or moreprocessors, as disclosed herein, that monitors registered devices foroutages, e.g., loss of network connections and/or power. In embodiments,the agent may monitor the registered devices for outages by querying theregistry 1129 (FIG. 1) using IoT UIDs 6118 for the registered devicesand analyzing returned device property data 6128 (FIG. 6). Monitoring bythe agent may be for a single device and/or for a fleet of devices, ormay be for one or more modules within a device and/or fleet of devices.As will be appreciated, in embodiments, the IoT device registrar 1130may be positioned to view a large number of devices simultaneously,where the devices may be spread across multiple entities, e.g.,distinct/different corporations, and/or geographic locations, which mayprovide for improved insight into the existence of an outage, ascompared to traditional systems.

In embodiments, the IoT device registrar may source network andecosystem information sources and/or correlate relevant data to visuallyshow, e.g., in a SPG, affected devices that may be unreachable due toweather, Mobile Network Operator outage, utility outage (power, water,gas, etc.) or other communications outage in a localized area affectingmultiple devices or customers (of the affected devices and/or servicesrelating to the affected devices). In embodiments, an agent/sentryresiding within the IoT device registry monitors relevant data feeds tocreate automated alerts, visual displays, and notifications among otheractions.

Accordingly, illustrated in FIG. 115 is an apparatus 115100 fordetecting down devices, e.g., 1112, 1114, 1116, 1118, 1120, 1122, and/or1124 (FIG. 1). The apparatus 115100 includes a device property dataprocessing circuit 115110, an outage detection circuit 115112, an alertcircuit 115114, and/or an alert provisioning circuit 115116. Theapparatus 115100 may form part of the server 1126 (FIG. 1), database1128 (FIG. 1), a computing device, e.g., a device management platform,operated by a manufacturer 1134 (FIG. 1), an end user 1136 (FIG. 1), athird party 1138 (FIG. 1), and/or any other computing device describedherein. The device property data processing circuit 115110 may bestructured to interpret device property data 6120 corresponding to oneor more devices 1112, 1114, 1116, 1118, 1120, 1122, and/or 1124registered with an IoT device registry 11129 (FIG. 1) via IoT UIDs 6118.The outage detection circuit 115112 is structured to detect an outagepattern 115118 in/from the device property data 6120. The outage pattern115118 may correspond to an outage of the one or more devices 1112,1114, 1116, 1118, 1120, 1122, and/or 1124. Outage patterns 115118 may bebased on correlations between events 6134 (FIG. 6), time values,ownership, manufacturers, device properties, and/or other type of data.The alert circuit 115114 is structured to, in response to the outagepattern 115118, generate an alert message 115120 that identifies the oneor more devices 1112, 1114, 1116, 1118, 1120, 1122, and/or 1124 affectedby and/or otherwise corresponding to the outage. The alert provisioningcircuit 115116 may be structured to transmit the alert message 115120which, in embodiments, may be to a device management platformcorresponding to an end user 1136, a manufacturer 1134, a third party1138, and/or other entity. In embodiments, the alert provisioningcircuit 115116 may be structured to transmit the alert message 115120 toany of the computing devices disclosed herein. The alert message 115120may include one or more IoT Universal Identifications (UIDs) 6118 (FIG.6) that correspond to one or more devices, e.g., 1112, 1114, that may beassociated with a detected outage. The alert message 115120 may includea code and/or short description that identifies the nature of thedetected outage, e.g., “a weather event is affecting devices located inHampden county”. The alert message 115120 may include one or more timevalues associated with the detected outage, e.g., a start time, a stoptime, and a predicted stop time, a duration, etc.

As shown in FIG. 116, the outage detection circuit 115112 may include anartificial (AI) intelligence circuit 116110 structured to detect theoutage pattern 115118 based at least in part on analyzing the deviceproperty data 6120 using an artificial intelligence process.Non-limiting examples of such artificial intelligence processes includeneural networks, deep-learning techniques, convolutional networks(including convolutional neural networks), and the like. In embodiments,the artificial intelligence process may include a neural network trainedto detect correlations between outage patterns 115118 and weatherevents, cyber-attacks, device failure events, device ownership, devicemanufacturer, location, network outages, and/or other data relating topossible properties and/or causes of an outage pattern. In embodiments,the artificial intelligence process may predict the occurrence of futureoutages. For example, the AI circuit 116110 may have access to weatherdata and predict outages for geographic regions that may be in apredicted path of a weather system, e.g., a hurricane. In embodiments,weather data may include solar data, e.g., solar storms. Accordingly,some embodiments of the AI circuit 132110 may predict outages involvingsatellites (or other devices affected by solar storms).

In embodiments, the apparatus 115100 may further include a visualizationcircuit 116112 structured to generate and/or transmit outagevisualization data 116124 structured/configured to depict avisualization of the outage and/or outage pattern 115118 on anelectronic display, such as on a SPG, e.g., 28102, 28104, and/or 28106(FIG. 28). Non-limiting examples of visualizations include maps, charts,listings, and the like. For example, embodiments of the outagevisualization data 116124 may generate a map that depicts thelocation(s) of one or more devices 1112, 1114, 1116, 1118, 1120, 1122,and/or 1124 experiencing an outage. In embodiments, the visualizationdata 116124 may generate a chart that shows statistical data relating toone or more devices 1112, 1114, 1116, 1118, 1120, 1122, and/or 1124affected by an outage, e.g., an amount, e.g., total, percentage,average, etc., of affected devices.

Illustrated in FIG. 117 is a method 117100 for detecting down devices.The method may be performed by the apparatus 115100 (FIG. 115) and/orany other computing device described herein. The method 117100 mayinclude interpreting, via a device property data processing circuit,device property data corresponding to one or more devices registeredwith an IoT device registry 117110. The method 117100 may furtherinclude detecting, via an outage detection circuit, an outage pattern inthe device property data 117112. The outage pattern may correspond to anoutage of the one or more devices, as disclosed herein. The method117110 may further include, responsive to the outage pattern,generating, via an alert circuit, an alert message that identifies theone or more devices 117114; and/or transmitting, via an alertprovisioning circuit, the alert message 117116.

As shown in FIG. 118, in embodiments of the method 117100, detecting anoutage pattern in the device property data 117112 may include detectingthe outage pattern via analyzing the device property data with anartificial intelligence circuit that uses an artificial intelligenceprocess, as disclosed herein, 118110. In embodiments, the method 117100may further include generating, via a visualization circuit,visualization data configured to depict a visualization of the outage onan electronic display 118112; and/or transmitting, via the visualizationcircuit, the visualization data 118114. In embodiments, the method117100 may further include interpreting the visualization data 118116,and/or displaying the visualization data 118118. In embodiment,interpreting the visualization data 118116 and/or the displaying thevisualization data 118118 may be performed by a device managementplatform and/or a corresponding SPG, as disclosed herein.

Referring to FIG. 119, a method 119100 of training an artificialintelligence (AI), e.g., the AI circuit 116110 (FIG. 116), to detectdevice outages and/or outage patterns is provided. The method 119100 maybe performed by the apparatus 115100 and/or any other computing devicedisclosed herein. The method 119100 incudes collecting a data setincluding one or more outage patterns and device property data 119110;and creating a first training set including one or more portions of thedevice property data that correspond to the one or more outage patterns119112. The method 119100 further includes creating a second trainingset comprising one or more portions of the device property data thatincorrectly identify the one or more outage patterns 119114. The method119100 further includes training the AI on the first training set119116, and training the AI on the second training set 119118.

As a non-limiting example, a plurality of devices 1112, 1114, 1116, 1118registered with the registry 1129 (1) may be in the possession of usersall within a same region, e.g., Massachusetts. A subset of the users andtheir corresponding devices 1114 and 1118 may be located in Boston,Mass. with other users/devices 1112 and 1116 respectively located inSpringfield, Mass. and Worcester, Mass. A device management platformoperated by a third-party monitoring service, e.g., 1138 (FIG. 1), mayperiodically check the connectivity status of the devices 1112, 1114,1116, 1118, and may send device event messages 6116 and/or status values6114 (FIG. 6) to the registry 1129 to update the applicablecorresponding records 6110, e.g., “device ‘A’ had good connectivity asof 5:25 pm ET.” As an example scenario, a car crash may occur anddisable and/or impact one or more 5G towers located in the GreaterBoston metropolitan area, resulting in the device management platform nolonger being able to contact the devices 1114 and 1118. Embodiments ofan agent executing on the apparatus 115100 (FIGS. 115 and 116) and/orperforming the method 117100 (FIGS. 117 and/or 134) may be periodicallychecking the records 1131 in the registry 1129 and detect that thedevice property data 6120 (FIGS. 115, and 116) for devices 1114 and 1118indicates that they are unreachable, while devices 1112 and 1116 arereachable. The agent may then determine that this difference in deviceproperty data corresponds to an outage, and in particular, an outagelocalized to the Greater Boston metropolitan area. The agent may thengenerate and transmit an alert message to the third-party monitoringservice 1138 indicating that devices 1114 and 1118 are unreachable andappear to be impacted by a network outage affecting only the GreaterBoston metropolitan area. The agent may then continue to monitor theregistry 1129, and may generate and send another alert message to thethird-party monitoring service 1138 when the records for the affecteddevices 1114 and 1118 indicate that the devices are reachable again.

Embodiments of the current disclosure may also provide for the detectionof manufacturing defects affecting devices made by a manufacturer, e.g.,1134 (FIG. 1). For example, embodiments of an agent executing on theapparatus 115100 (FIGS. 115 and 116) and/or performing the method 117100(FIGS. 117 and/or 134) may be periodically checking the records 1131 inthe registry 1129 and detect that the device property data 6120 (FIGS.6, 115, and 116) for one or more devices manufactured by a manufacturer1134, which may be in the possession of different end users, indicatesthat such devices experience common malfunctions. For example, theuseful lives of the batteries of the one or more devices may appear tobe shorter than industry norms, regardless of the operating conditionsexperienced by the devices.

Embodiments of the current disclosure may also provide for the detectionof cyber-attacks affecting particular types of devices. For example,embodiments of an agent executing on the apparatus 115100 (FIGS. 115 and116) and/or performing the method 117100 (FIGS. 117 and/or 118) may beperiodically checking the records 1131 in the registry 1129 and detectthat the device property data 6120 (FIGS. 6, 115, and 116) for one ormore devices of a same type, and/or having similar software and/orfirmware components, have been experiencing system compromises, whileother devices not of the same type have not been experiences the sametype of system compromises at the same rate.

In a non-limiting example, an agent executing on the apparatus 115100(FIGS. 115 and 116) and/or performing the method 117100 (FIGS. 117and/or 134) may be periodically checking the records 1131 in theregistry 1129 and detect that the device property data 6120 (FIGS. 6,115, and 116) for devices associated with a mobile virtual networkoperator (MVNO) and in the possession of end user subscribers of theMVNO. The MVNO may use a device management platform and/or SPG, asdisclosed herein, to monitor for device outages and providenotifications to the end users of the existence of an outage and/orexpected recovery from the outage.

In a non-limiting example, one or more devices experiencing an outage ofa first network connection may generate and transmit event messages(indicating a network outage with the first network connection) over asecond network connection. Such event messages may be transmitted to adevice management platform and/or to an IoT device registrar, asdisclosed herein.

Referring again to FIGS. 1 and 2, embodiments of the current disclosuremay provide for detection of fraudulent activity, e.g., regardingInternet of Things (IoT) devices. Fraudulent activity or activities,also referred to herein as fraud, a fraud event, theft, security risk,tampering, unusual behavior, fraudulent behavior, unauthorized access,counterfeiting, and/or the like, may be a device, e.g., 1112, 1114,1116, 1118, 1120, 1122, and/or 1124 (FIG. 1), that is experiencing, hasexperienced, and/or is likely to experience a fraud event. Non-limitingexamples of fraudulent activity include: cyber-attacks; outdatedsoftware and/or firmware; unauthorized software and/or firmware changes;hardware changes; unauthorized access to the device; unauthorized accessby the device, e.g., to an IoT registry server; disabled networkconnections; malfunctioning network components, e.g., routers, towers,relays, fiber and/or coaxial lines, DNS servers, etc.; power issues,e.g., low battery power, no battery power, excessive battery power;sensor issues, e.g., temperature, pressure, voltage, conductivity,amperage, etc.; user input device malfunctions, e.g., broken touchscreens, broken keyboards, broken mice; and/or other types ofabnormalities. Fraudulent activity may also include spoofing of aretired device and/or spoofing of its components, e.g., a use ofcellular network access credentials of a retired device, a use oflicense credentials of a retired device, providing a deliberatelyinaccurate and/or manually-entered GPS location of a device, and/or ause of an unauthorized or fake license for a device, by one or moreunauthorized devices. In embodiments, apparatus and/or processes thatprovide for the detection of fraudulent activity, as disclosed herein,may form part of the registry 1129, e.g., the usage and trend analysissubcomponent 2130, the detect unusual behavior subcomponent 2132, and/ora set service alerts subcomponent 2134. Embodiments of the currentdisclosure may provide for a fraud detection device, which may also bereferred to herein as a sentry or an agent, that may include one or moreof the apparatuses and/or perform one or more of the methods, disclosedherein, for detection of fraudulent activity or activities. Inembodiments, the devices and/or processes that provide for the detectionof fraudulent activity, as disclosed herein, may form part of a devicemanagement platform operated by a manufacturer 1134, an end user 1136,and/or a third party 1138. Embodiments of the current disclosure mayprovide for an agent, e.g., the sentry, that executes on one or moreprocessors, as disclosed herein, that monitors registered devices forfraudulent activity, e.g., unauthorized device access, messagetransmissions, and/or illegal and/or other unauthorized activities.Monitoring by the agent may be for a single device and/or for a fleet ofdevices, or may be for one or more modules within a device and/or fleetof devices. As will be appreciated, in embodiments, the IoT deviceregistrar 1130 may be positioned to view a large number of devicessimultaneously, where the devices may be spread across multipleentities, e.g., distinct/different corporations, and/or geographiclocations, which may provide for improved insight into the existence offraudulent activity, as compared to traditional systems.

In embodiments, machine learning and/or other pattern recognitiontechniques may be used to generate and/or correlate information ondevice relationships that are behaving ‘normally’ to establish abaseline. Such embodiments may also provide for ‘alerts’ when abnormalbehavior patterns are detected, e.g., behavior patterns outside theestablished baseline. In embodiments, the baseline may be generated byan agent/sentry in the registry 1129 (FIG. 1) and/or any other computingdevice disclosed herein.

FIG. 120 depicts a schematic diagram of an example apparatus 120100 fordetecting fraudulent activity, e.g., for network connected devices 1112,1114, 1116, 1118, 1120, 1122, 1124 (FIG. 1), in accordance with anembodiment of the current disclosure. The apparatus 120100 may form partof the server 1126 (FIG. 1), e.g., the at least one processor, and/orany other electronic computing device described herein.

With reference to FIG. 120, the apparatus 120100 may include a deviceproperty data processing circuit 120102, a security analysis circuit120104, an alert circuit 120106, and an alert provisioning circuit120108. The device property data processing circuit 120102 may bestructured to interpret device property data 120110 corresponding to adevice, e.g., any of devices 1112, 1114, 1116, 1118, 1120, 1122, 1124(FIG. 1), registered with an Internet of Things (IoT) device registry,e.g., registry 1129 (FIG. 1). The security analysis circuit 120104 maybe structured to determine, based at least in part on the deviceproperty data 120110, that the device may be subject to a fraud event,which may be an internal fraud event 120112 and/or an external fraudevent 120140. The alert circuit 120106 may be structured to generate,responsive to the determined fraud event 120112, 120140, a message120114 that identifies the device. The alert provisioning circuit 120108may be structured to transmit the message 120114.

Certain further aspects of the example apparatus are described herein,any one or more of which may be present in certain embodiments. In theapparatus 120100, the security analysis circuit may include anartificial intelligence (AI) circuit 120116 structured to detect thefraud event, based at least in part on analyzing the device propertydata using an artificial intelligence process. In the apparatus 120100,the artificial intelligence process may include a neural network. In theapparatus 120100, the neural network may be trained on detectingcorrelations between the fraud event and at least one of: acyber-attack, a software version, a firmware version, a hardwareversion, an unauthorized access, a device failure event, deviceownership, a device manufacturer, a location, or a network outage,unauthorized device access, use of property data corresponding to aretired/decommissioned device, etc. In the apparatus 120100, theartificial intelligence process may be based at least in part on a deeplearning network. The apparatus 120100 may further include avisualization circuit 120118 structured to generate and transmit fraudevent visualization data 120120 configured to depict a visualization ofthe fraud event on an electronic display. In the apparatus 120100, thevisualization may be a map. In the apparatus 120100, the visualizationmay be a chart depicting at least one of the devices affected by thefraud event. In the apparatus 120100, the alert provisioning circuit maybe further structured to transmit the message to at least one of: adevice management platform corresponding to the device, a user of thedevice, a manufacturer of the device, or an entity that monitors thedevice. In the apparatus 120100, the security analysis circuit may formpart of a device management platform. In the apparatus 120100, thesecurity analysis circuit may form part of the IoT device registry,e.g., registry 1129 (FIG. 1). The apparatus 120100 may further include adisplay circuit 120122 structured to display the message. The apparatus120100 may further include a fraud event log circuit 120124 structuredto log the fraud event in a database 120126, e.g., database 1128 (FIG.1), which may form part of the apparatus 120100 or may be external tothe apparatus 120100. The apparatus 120100 may further include a devicemanagement platform 120128 structured to interpret the messagetransmitted by the alert provisioning circuit, and at least one of:quarantine the at least one device, disable the at least one device,disable at least part of the device, disable at least some functionalityof the device, send an alert to the device, send an alert to an entityassociated with the device, or patch the at least one device.

The apparatus 120100 may further include a trust indicator provisioningcircuit 120130 structured to provide a trust indicator 120132 for thedevice, based at least in part on the determined fraud event. In theapparatus 120100, the trust indicator may include any of a numericvalue, an alphabetic value, and/or an alphanumeric value. In theapparatus 120100, the trust indicator may include an enumerated value.In the apparatus 120100, the trust indicator may be displayed as acolor-coded value. In the apparatus 120100, a value of the trustindicator may be based at least in part on a location of the device. Inthe apparatus 120100, a value of the trust indicator may be based atleast in part on a time period. In the apparatus 120100, a value of thetrust indicator may be based at least in part on one or more of asoftware version or a firmware version of the device. In the apparatus120100, determining the trust indicator may be based at least in part onartificial intelligence. In the apparatus 120100, the trust indicatormay be reflective of the device being a Greenfield device, as disclosedherein. In the apparatus 120100, the trust indicator may be reflectiveof the device being a Brownfield device, as disclosed herein. In theapparatus 120100, the trust indicator may be reflective of the devicebeing a virtual device, as disclosed herein. In the apparatus 120100,the trust indicator may be reflective of the device being a meta-device,as disclosed herein.

For example, devices may be virtual devices, e.g., objects in ametaverse having real-world counterparts (real-world devices), where thevirtual device is a digital-twin of the real-world counterpart. Adigital virtual device may have properties corresponding to itsreal-world counterpart that may be updated in real-time and/or on aperiodic basis. Devices in the metaverse may be real-world devices,e.g., objects in the real-world having metaverse counterparts (digitaltwin virtual devices) and/or supporting metaverse activities. As anotherexample, devices may be meta-devices, e.g., objects in the metaverselacking real-world counterparts. In embodiments, a device may havemodules that are virtual devices and modules that are meta-devices. Inembodiments, an IoT device registry may provide for registration ofvirtual devices, real-world devices, and/or meta-devices, as disclosedherein, and/or the services and/or functions associated withregistration for registered virtual devices, real-world devices, and/ormeta-devices, as also disclosed herein. Any of virtual devices,real-world devices, and/or meta-devices may be Greenfield devices and/orBrownfield devices, and/or may have a combination of Greenfield modulesand/or Brownfield modules.

In the apparatus 120100, the trust indicator may be displayed as atleast one of: numeric based, color based, symbol based, alphanumericbased, letter based, or any combination thereof. In the apparatus120100, the trust indicator provisioning circuit may be furtherstructured to adjust a value of the trust indicator based at least inpart on the determined fraud event. In the apparatus 120100, theadjustment may be an increase when the determined fraud eventcorresponds to at least one of a patching or an updating of at least oneof software or firmware of the device. In the apparatus 120100, theadjustment may be a decrease when the determined fraud event correspondsto a cyber-attack.

In the apparatus 120100, the determined fraud event may correspond to anaddition of a new module into the device. As a non-limiting example, thenew module added to the device may be new software/firmware/hardwareand/or a change in the existing software/firmware/hardware and/or achange in the external environment that results in the currentsoftware/firmware/hardware being exploitable. For example, a newvulnerability may become known. In the apparatus 120100, the new modulemay be at least one of an input device or an output device. In theapparatus 120100, the at least one of the input device or the outputdevice may be a network interface device. In the apparatus 120100, theat least one of the input device or the output device may be a mediadevice. In the apparatus 120100, the determined fraud event maycorrespond to a change in ownership of the device. In the apparatus120100, the determined fraud event may be based on detecting a change ina location of the device. In the apparatus 120100, the determined fraudevent may be based on detecting a change in at least one of a softwareversion or a firmware version of the device. In the apparatus 120100,the determined fraud event may be based on detecting a change in ahardware version of the device. The apparatus may further include an IoTUniversal Identification (UID) processing circuit 120134 structured tointerpret an IoT UID and the device property data, a record managementcircuit 120136 structured to associate the IoT UID with the deviceproperty data via a record, and a record provisioning circuit 120138structured to transmit the record.

FIG. 121 illustrates a flowchart of an example method 121100 fordetecting fraudulent activity, e.g., for network connected devices 1112,1114, 1116, 1118, 1120, 1122, 1124 (FIG. 1), in accordance with anembodiment of the current disclosure. The method 121100 may be performedby the apparatus 120100 and/or any other computing device describedherein.

The method 121100 may include interpreting, via a device property dataprocessing circuit, device property data corresponding to a device,e.g., any of devices 1112, 1114, 1116, 1118, 1120, 1122, 1124 (FIG. 1),registered with an Internet of Things (IoT) device registry 121102,e.g., registry 1129 (FIG. 1). The method 121100 may further includedetermining, via a security analysis circuit based at least in part onthe device property data, that the device is subject to a fraud event121104. The fraud event may be an internal fraud event and/or anexternal fraud event. The method 121100 may further include generating,responsive to the determined fraud event, via an alert circuit, amessage that identifies the device 121106. The method 121100 may furtherinclude transmitting, via an alert provisioning circuit, the message121108.

FIG. 122 is another flowchart depicting a method for detectingfraudulent activity, in accordance with an embodiment of the currentdisclosure. FIG. 123 is another flowchart depicting a method for an IoTdevice registry display, in accordance with an embodiment of the currentdisclosure. Certain further aspects of the example method are describedherein, any one or more of which may be present in certain embodiments.The features shown in FIGS. 121, 122, and 123 are combinable andinterchangeable in any configuration in embodiments. With reference toFIG. 122, in the method 121100, the determining, via the securityanalysis circuit, that the device is subject to a fraud event mayinclude detecting the fraud event via analyzing the device property datawith an artificial intelligence circuit that uses an artificialintelligence process 122102. In the method 121100, the artificialintelligence process may include a neural network. The method 121100 mayfurther include training the neural network on detecting correlationsbetween the fraud event and at least one of: a cyber-attack, a softwareversion, a firmware version, a hardware version, an unauthorized access,a device failure event, device ownership, a device manufacturer, alocation, a network outage 122104, property data common between analleged authorized device and a known retired/decommissioned device,and/or the like. In the method 121100, the artificial intelligenceprocess may be based at least in part on a deep learning network. Themethod 121100 may further include generating and transmitting, via avisualization circuit, fraud event visualization data configured todepict a visualization of the fraud event on an electronic display122106. In the method 121100, the visualization may be a map. In themethod 121100, the visualization may be a chart depicting at least oneof the device affected by the fraud event. The method 121100 may furtherinclude transmitting, via the alert provisioning circuit, the message toat least one of: a device management platform corresponding to thedevice, a user of the device, a manufacturer of the device, or an entitythat monitors the device 122108. In the method 121100, the securityanalysis circuit may form part of a device management platform. In themethod 121100, the security analysis circuit may form part of the IoTdevice registry. The method 121100 may further include displaying themessage via a display circuit 122110. The method 121100 may furtherinclude logging the fraud event in a database via a fraud event logcircuit 122112.

With reference to FIG. 123, the method 121100 may further includeinterpreting, via a device management platform, the message transmittedby the alert provisioning circuit 123102, and by the device managementplatform, at least one of: quarantining the device 123104, disabling thedevice 123106, disable at least part of the device 123116, disable atleast some functionality of the device 123118, send an alert to thedevice 123120, send an alert to an entity associated with the device, orpatching the device 123108. The method 121100 may further includeproviding a trust indicator for the device, based at least in part onthe determined fraud event 123110. In the method 121100, the trustindicator may include any of a numeric value, an alphabetic value,and/or an alphanumeric value. In the method 121100, the trust indicatormay include an enumerated value. In the method 121100, the trustindicator may be displayed as a color-coded value. In the method 121100,a value of the trust indicator may be based at least in part on alocation of the device. In the method 121100, a value of the trustindicator may be based at least in part on a time period. In the method121100, a value of the trust indicator may be based at least in part onat least one of a software version or a firmware version of the device.In the method 121100, determining the trust indicator may be based atleast in part on artificial intelligence. In the method 121100, thetrust indicator may be reflective of the device being a Greenfielddevice. In the method 121100, the trust indicator may be reflective ofthe device being a Brownfield device. In the apparatus 120100, the trustindicator may be reflective of the device being a virtual device, asdisclosed herein. In the apparatus 120100, the trust indicator may bereflective of the device being a meta-device, as disclosed herein.

In the method 121100, the trust indicator may be displayed as at leastone of: numeric based, color based, symbol based, alphanumeric based,letter based, or any combination thereof. The method 121100 may furtherinclude adjusting a value of the trust indicator based at least in parton the determined fraud event 123112. In the method 121100, theadjusting may be an increase when the determined fraud event correspondsto at least one of a patching or an updating of at least one of softwareor firmware of the device. In the method 121100, the adjusting may be adecrease when the determined fraud event corresponds to a cyber-attack.

In the method 121100, the determined fraud event may correspond to anaddition of a new module into the device. In the method 121100, the newmodule may be at least one of an input device or an output device. Inthe method 121100, the at least one of the input device or the outputdevice may be a network interface device. In the method 121100, the atleast one of the input device or the output device may be a mediadevice. In the method 121100, the determined fraud event may correspondto a change in ownership of the device. In the method 121100, thedetermined fraud event may be based on detecting a change in a locationof the device. In the method 121100, the determined fraud event may bebased on detecting a change in at least one of a software version or afirmware version of the device. In the method 121100, the determinedfraud event may be based on detecting a change in a hardware version ofthe device. The method 121100 may further include accessing, by thesecurity analysis circuit, a fraud event database to interpret fraudevent signatures to determine that the device is subject to the fraudevent 123114. A fraud event signature may include a set of events and/ordata values known to be associated with past fraud events, and/or a setof events and/or data values similar to events and/or data values knownto be associated with past fraud events, e.g., recent use of a long-agoretired SIM card and/or MAC address. The method 121100 may furtherinclude interpreting, via an IoT UID processing circuit, an IoT UID andthe device property data 123122, associating, via a record managementcircuit, the IoT UID with the device property data via a record 123124,and transmitting, via a record provisioning circuit, the record 123126.

FIG. 124 depicts a schematic diagram of an example apparatus 124100 fordetecting fraudulent activity, e.g., for network connected devices 1112,1114, 1116, 1118, 1120, 1122, 1124 (FIG. 1), in accordance with anembodiment of the current disclosure. The apparatus 124100 may form partof the server 1126 (FIG. 1), e.g., the at least one processor, and/orany other electronic computing device described herein.

With reference to FIG. 124, the apparatus 124100 may include a deviceproperty data processing circuit 124102, a change detection circuit124104, a fraud detection circuit 124106, an alert circuit 124108, andan alert provisioning circuit 124110. The device property dataprocessing circuit 124102 may be structured to, at a first time,interpret device property data 124112 corresponding to a device, e.g.,any of devices 1112, 1114, 1116, 1118, 1120, 1122, 1124 (FIG. 1),registered with an IoT device registry, e.g., registry 1129 (FIG. 1);and at a second time, interpret the device property data 124112corresponding to the device registered with the IoT device registry. Thechange detection circuit 124104 may be structured to detect a change124114 in the device property data 124112 between the first time and thesecond time. The fraud detection circuit 124106 may be structured todetermine that the change corresponds to a fraud event, which may be aninternal fraud event 124116 and/or an external fraud event 124122. Thealert circuit 124108 may be structured to generate, responsive to thedetermining that the change corresponds to a fraud event 124116, 124122,a message 124118 that identifies the device corresponding to the deviceproperty data 124112. The alert provisioning circuit 124110 may bestructured to transmit the message 124118.

Certain further aspects of the example apparatus are described herein,any one or more of which may be present in certain embodiments. In theapparatus 124100, the fraud detection circuit 124106 may include anartificial intelligence circuit 124120 structured to detect the 124116,124122, based at least in part on analyzing the device property data124112 using an artificial intelligence process. In the apparatus124100, the artificial intelligence process may include a neuralnetwork. In the apparatus 124100, the neural network may be trained ondetecting correlations between the fraud event 124116, 124122 and atleast one of: a cyber-attack, a software version, a firmware version, ahardware version, an unauthorized access, a device failure event, deviceownership, a device manufacturer, a location, or a network outage.

FIG. 125 illustrates a flowchart of an example method 125100 fordetecting fraudulent activity, e.g., for network connected devices 1112,1114, 1116, 1118, 1120, 1122, 1124 (FIG. 1), in accordance with anembodiment of the current disclosure. The method 125100 may be performedby the apparatus 120100 and/or any other computing device describedherein. The method 125100 may include at a first time, interpreting, viaa device property data processing circuit, device property datacorresponding to a device, e.g., any of devices 1112, 1114, 1116, 1118,1120, 1122, 1124 (FIG. 1), registered with an IoT device registry125102, e.g., registry 1129 (FIG. 1). The method may further include, ata second time, interpreting, via the device property data processingcircuit, the device property data corresponding to the device registeredwith the IoT device registry 125104. The method may further includedetecting, via a change detection circuit, a change in the deviceproperty data between the first time and the second time 125106. Themethod may further include determining, by a fraud detection circuit,that the change corresponds to a fraud event 125108. The method mayfurther include generating, via an alert circuit and responsive to thedetermining that the change corresponds to a fraud event, a message thatidentifies the device corresponding to the device property data 125110.The method may further include transmitting, via an alert provisioningcircuit, the message 125112.

FIG. 126 is another flowchart depicting a method for an IoT deviceregistry display, in accordance with an embodiment of the currentdisclosure. Certain further aspects of the example method are describedas following, any one or more of which may be present in certainembodiments. The features shown in FIGS. 125 and 126 are combinable andinterchangeable in any configuration in embodiments. With reference toFIG. 126, in the method 125100, the determining, via the fraud detectioncircuit, that the change corresponds to a fraud event may includedetecting the fraud event via analyzing the device property data with anartificial intelligence circuit that uses an artificial intelligenceprocess 126102. In the method 125100, the artificial intelligenceprocess may include a neural network. The method 125100 may furtherinclude training the neural network on detecting correlations betweenthe fraud event and at least one of: a cyber-attack, a software version,a firmware version, a hardware version, an unauthorized access, a devicefailure event, device ownership, a device manufacturer, a location, or anetwork outage 126104.

FIG. 127 depicts a schematic diagram of an example system 127100 fordetecting fraudulent activity, e.g., for network connected devices 1112,1114, 1116, 1118, 1120, 1122, 1124 (FIG. 1), in accordance with anembodiment of the current disclosure. The system 127100 may form part ofthe server 1126 (FIG. 1), e.g., the at least one processor, and/or anyother electronic computing device described herein.

With reference to FIG. 127, the system 127100 may include a devicemanagement platform 127102 and a fraud detection device 127104. Thedevice management platform 127102 may be structured to manage one ormore devices, e.g., any of devices 1112, 1114, 1116, 1118, 1120, 1122,1124 (FIG. 1), registered with an IoT device registry, e.g., registry1129 (FIG. 1). The fraud detection device 127104 may be structured tomonitor the IoT device registry for changes in device property data127106 corresponding to the registered one or more devices, detect achange 127108 in the device property data 127106 for at least one deviceamong the one or more devices, determine that the detected change 127108corresponds to a fraud event 127110, generate, responsive to thedetermined fraud event 127110, a message 127112 that identifies the atleast one device, transmit the message 127112 to the device managementplatform. The fraud event 127110 may be an internal fraud event and/oran external fraud event. The device management platform 127102 may befurther structured to interpret the message 127112 transmitted by thefraud detection device 127104, and at least one of: quarantine the atleast one device, disable the at least one device, disable at least partof the device, disable at least some functionality of the device, sendan alert to the device, send an alert to an entity associated with thedevice, or patch the at least one device.

Certain further aspects of the example system are described asfollowing, any one or more of which may be present in certainembodiments. In the system 127100, the fraud detection device 127104 mayinclude an artificial intelligence circuit 127114 structured to detectthe fraud event 127110, based at least in part on analyzing the deviceproperty data 127106 using an artificial intelligence process. In thesystem 127100, the artificial intelligence process may include a neuralnetwork. In the system 127100, the neural network may be trained ondetecting correlations between the fraud event 127110 and at least oneof: a cyber-attack, a software version, a firmware version, a hardwareversion, an unauthorized access, a device failure event, deviceownership, a device manufacturer, a location, or a network outage.

FIG. 128 illustrates a flowchart of an example method 128100 fordetecting fraudulent activity, e.g., for network connected devices 1112,1114, 1116, 1118, 1120, 1122, 1124 (FIG. 1), in accordance with anembodiment of the current disclosure. The method 128100 may be performedby the apparatus 120100 and/or any other computing device describedherein.

The method 128100 may include monitoring, via at least one processor,one or more records in an IoT device registry for changes in deviceproperty data corresponding to one or more devices, e.g., any of devices1112, 1114, 1116, 1118, 1120, 1122, 1124 (FIG. 1), each of the one ormore devices corresponding to one of the one or more records 128102. Themethod 128100 may further include detecting, via the at least oneprocessor, a change in the device property data of at least one recordamong the one or more records 128104. The method 128100 may furtherinclude determining, via the at least one processor, that the changecorresponds to a fraud event 128106. The method 128100 may furtherinclude generating, via the at least one processor and responsive to thedetected fraud event, a message that identifies the device,corresponding to the changed device property data 128108. The method128100 may further include transmitting, via the at least one processor,the message 128110.

FIG. 129 is another flowchart depicting a method for an IoT deviceregistry display, in accordance with an embodiment of the currentdisclosure. Certain further aspects of the example method are describedas following, any one or more of which may be present in certainembodiments. The features shown in FIGS. 128 and 129 are combinable andinterchangeable in any configuration in embodiments. With reference toFIG. 129, in the method 128100, the determining that the changecorresponds to a fraud event may include detecting the fraud event viaanalyzing the device property data with an artificial intelligencecircuit that uses an artificial intelligence process 129102. In themethod 128100, the artificial intelligence process may include a neuralnetwork. The method 128100 may further include training the neuralnetwork on detecting correlations between the fraud event and at leastone of: a cyber-attack, a software version, a firmware version, ahardware version, an unauthorized access, a device failure event, deviceownership, a device manufacturer, a location, or a network outage129104.

In certain embodiments, the determination or detection of fraudulentactivity may include identification of a trust level, score, and/orrating, which may be dynamic. Correlation of device properties acrossthe various spectrums may provide for a unique ability to detect unusualrelationships that may indicate fraud and/or warrant furtherinvestigation. Embodiments may send messages to various parties, e.g.,manufacturers, such as an original equipment manufacturer (OEM), thatinclude restricted views of device property data, which may enable thevarious parties to detect unusual behavior and/or fraud. Embodiments mayprovide for the detection of device properties, e.g., location, usageprofile, network, interface language, device settings, associatedtelephone number, which may be indicative of a change in ownership.

Embodiments of the current disclosure may also provide for alertmanagement, for example, the setting and triggering of alerts based onconditional logic, e.g., risk management 5128, compliance management5130, and/or security 5132 (FIG. 5). For example, the owner and/oroperators of a network connected device may set alerts configured tonotify the owner and/or operator of unusual activity associated with oneor more network connected devices. Embodiments of the current disclosuremay also provide for analysis of data corresponding to the networkconnected devices, e.g., usage and/or trend data, risk management data,data compliance management, etc. Such analysis may be performed by theregistration server, e.g., server 1126 (FIG. 1) on data retrieved fromthe plurality of records 1131 (FIG. 1). Risk analysis may be based atleast in part on the attributes of one or more network connecteddevices, e.g., lifecycle events reflected by changes of a networkconnected device's attributes as recorded in its corresponding record,e.g., record 1152 (FIG. 1).

Referring to FIG. 130, embodiments of the current disclosure may providefor registering meta-devices with an Internet of Things (IoT) deviceregistry 1129 (FIG. 1). A meta-device, in embodiments, may be a deviceand/or module that exists in a computer environment, e.g., a metaverse,a virtual environment apart from a metaverse, a software object, etc. Ameta-device may have one or more real-world counterparts, or noreal-world counterparts. A meta-device with at least one real-worldcounterpart may be a virtual device, as disclosed herein. A meta-devicemay have a set of properties forming a unique signature for themeta-device, e.g., device property data, which may include one or morenon-fungible tokens (NFTs) and/or other properties as disclosed herein.Non-limiting examples of meta-devices lacking real-world counterpartsinclude: in-game objects, e.g., a sword in an online Role Playing Game(RPG), a building, in-game items for purchase, and the like; programmingconstructs, e.g., a database object, a programming application interface(API), a software development library, and the like; virtual screens;virtualized computer assets (virtual machines), and the like.Non-limiting examples of meta-devices having real-world counterpartsinclude: virtual shipping assets, e.g., ships, trucks, planes, and thelike; sensors, e.g., temperature, pressure, vibrational, and the like. Ameta-device may be a Greenfield device or a Brownfield device, asdisclosed herein. A non-limiting use case of registering a meta-deviceincludes a programmer registering a newly programmed and instantiatedcar for use in a multi-player/avatar virtual environment, e.g., ameta-verse, with an IoT device registrar as a Greenfield meta-device.The car may then be purchased by a user/customer where event messages,as disclosed herein, are transmitted to the IoT device registrar totrack the life cycle events of the car. The car may also have an NFTwhich is stored by the registry 1129 as part of the device propertydata. As another non-limiting example, a user in a meta-verse maypurchase a used vehicle (existing in the meta-verse) which they mayregister as a Brownfield device, as disclosed herein. In embodiments, ameta-device may be a point-of-sale device in a virtual convenience storewhere the meta-device may correspond to multiple real-world devices thatare not real-world point-of-sale devices (in the traditional sense),e.g., a server, payment gateway, and/or a firewall. The real-worlddevices, e.g., server, payment gateway, firewall, etc., may be atdifferent physical locations, e.g., different rooms in a building,different buildings in a city, different cities, differentstates/provinces, different regions, different countries, etc.

Accordingly, as shown in FIG. 130, a method 130100 for registering oneor more meta-devices may include an operation 130102 of interpreting,via an Internet of Things (IoT) Universal Identification (UID)processing circuit, an IoT UID and device property data corresponding toa meta-device, an operation 130104 of associating, via a recordmanagement circuit, the IoT UID with the device property data in arecord in a database, and an operation 130108 of transmitting, via arecord provisioning circuit, the record. For example, a corporation mayhave a digital T-shirt for display that they may want to give toreal-word shareholders. The corporation may hire a programmer to writethe software corresponding to the T-shirt, where the programmerregisters the T-shirt class object and/or associated software files withthe IoT device registry 1129. The programmer may then transfer ownershipand/or possession of the T-shirt class object to the corporation whothen creates and registers instances of the T-shirt, where each T-shirtmay be an NFT.

Referring to FIG. 131, a procedure 131101 may further include anoperation 131110 of transmitting at least one of the IoT UID or therecord to a user in a virtual environment. For example, continuing withthe virtual corporate T-shirt scenario, the corporation may distributethe T-shirts to the shareholders, where the shareholders can query theIoT UID in the IoT device registry 1129 to verify the history and/orother data in a corresponding record for the T-shirt.

Referring to FIG. 132, a procedure 132103 may further include anoperation 132112 of displaying at least one of the IoT UID or the recordin a virtual environment. Displaying the record in a virtual environmentmay provide a user of a virtual environment to read the record withouthaving to exit the virtual environment. As will be appreciated,displaying the IoT UID and/or the corresponding record in the virtualenvironment may improve the likelihood that users in the virtualenvironment will examine the information of a meta-device, e.g., riskand/or trust score, without having to leave the virtual environment.

As such, referring to FIG. 133, a procedure 133105 may further includean operation 133114 of generating at least one of a trustindicator/score or a risk indicator/score for the meta-device; andstoring the trust indicator/score or the risk indicator/score in therecord associated with the IoT UID.

Referring to FIG. 134, a procedure 134107 may further include anoperation 134118 of transmitting the trust indicator/score or the riskindicator/score to a user in a virtual environment.

Referring to FIG. 135, a procedure 135109 may further include anoperation 135120 of displaying the trust indicator/score or the riskindicator/score in a virtual environment in relation to the meta-device.

Referring to FIG. 136, an apparatus 136102 includes an IoT UIDprocessing circuit 136104 structured to interpret an IoT UID 6118 anddevice property data 136114 corresponding to a meta-device 136118. Theapparatus 136102 may also include a record management circuit 136108structured to associate the IoT UID 6118 with the device property data136114 via a record 136120. The apparatus 136102 may also include arecord provisioning circuit 136110 structured to transmit the record136120. The apparatus 136102 may further include an authenticationcircuit 136122 structured to generate at least one of a trustindicator/score 136124 or a risk indicator/score 136128 for themeta-device 136118, and store the trust indicator/score 136124 or therisk indicator/score 136128 in the 136120 record associated with the IoTUID 6118. In some embodiments, the meta-device 136118 may lack areal-world counterpart 136130. In some embodiments, the meta-devicelacks a real-world counterpart and a trust and/or risk score/indicatoris displayed in the real-world, e.g., a trust score displayed on an SPGfor a virtual server. In some embodiments, the meta-device 136118 mayhave at least one real-world counterpart 136130. In some embodiments,the meta-device 136118 may have at least two real-world counterparts136130. The at least two real-world counterparts 136130 may be indifferent locations. For example, the different locations may bedifferent rooms, buildings, states, countries, vehicles, or the like. Asa non-limiting example, a store in a meta-verse may have multiplegoods/items and/or services that are provided by servers existing indifferent countries.

With reference to FIG. 137, in some embodiments, the device propertydata 136114 may be at least one of an NFT 137102, an owner identifiervalue 137104, a manufacturer identifier value 137108, a Trusted PlatformModule (TPM) Key 137110, a Media Access Control (MAC) address 137112, aserial number 137114, a software version 137118, or a firmware version137120. The meta-device 136118 may be at least one of a Greenfielddevice 136132 or a Brownfield device 136134.

Referring to FIG. 138, an apparatus 138102 includes an IoT UIDprocessing circuit 138104 structured to interpret an IoT UID 6118associated with a meta-device 138118. The apparatus 138102 may furtherinclude a device lookup circuit 138108 structured to generate a query138120 that includes the IoT UID 6118 and is structured to retrievedevice property data 138114 corresponding to the IoT UID 6118. Theapparatus 138102 may further include a query provisioning circuit 138110structured to transmit the query 138120 to an IoT device registrarserver 1126. In an embodiment, the meta-device 138118 may lack areal-world counterpart. In some embodiments, the meta-device lacks areal-world counterpart, and a trust and/or risk score/indicator isdisplayed in the real-world. In an embodiment, the meta-device 138118may have at least one real-world counterpart. In an embodiment, themeta-device 138118 may have at least two real-world counterparts. The atleast two real-world counterparts may be in different locations. Forexample, the different locations may be different rooms, buildings,states, countries, vehicles, or the like. The device property data138114 may be at least one of an NFT, an owner identifier value, amanufacturer identifier value, a Trusted Platform Module (TPM) Key, aMedia Access Control (MAC) address, a serial number, a software version,or a firmware version, as in FIG. 137.

Illustrated in FIG. 139 is a supply chain for vaccine distribution whereone or more manufacturers 139132 produce a vaccine administered 139110by a medical professional to an individual. The present vaccinedistribution supply chain is one or many non-limiting examples involvingregistered tracking devices and, as such, embodiments of the presentdisclosure may be applicable to tracking devices for other types ofgoods and/or services.

As shown in FIG. 139, packages/units of the vaccine may follow multiplepaths, collectively represented by line 139112. As will be understood,packages of the vaccine may change ownership and/or move throughdifferent zones of liability, e.g., administrative regions havingboundaries where liability for the vaccines changes from one entity toanother. For example, a shipping company may have liability for units ofthe vaccine while in transport via an airplane 139114 wherein liabilitytransfers to the owner of a distribution center 139116 upon delivery ofthe vaccine to the distribution center 139116. Units of the vaccine maythen change ownership and/or have a change in liability upon beingshipped, e.g., via trucks 139118, to a hospital 139120 foradministration 139110 to a patient. Ownership of and/or liability forthe units of vaccine may change again upon delivery to the hospital139120. As will be understood, devices, as disclosed herein, may be usedto track the temperature and/or seal of the units of vaccine as theytravel though the supply chain. Such tracking may be required bygovernment regulations, e.g., the Center for Disease Control (CDC) mayrequire that tracking results 139122 be generated and sent to the CDC.Additionally, medical professionals and consumer/patients may requiresuch tracking in order to maintain confidence in the safety and/oreffectiveness of units of the vaccine. In embodiments, devices used totrack units of the vaccine through the supply chain may bedecommissioned 139124 and/or recycled once the vaccine has beenadministered. Government and/or industry regulations may control when adevice may be recycled though a supply chain and/or must be retired fromservice. As will be appreciated, embodiments of the current disclosuremay generate notifications and/or other types of messages indicatingwhether a device may be recycled through the supply chain and/or shouldbe decommissioned. Embodiments of the current disclosure may detectfailure to decommission a device, when decommission is called for by agovernment and/or industry standard, as an unusual event. Thus, entitiesoperating within the supply chain can verify with the registry 1129(FIG. 1) that devices are operating in accordance with government and/orindustry standard prior to accepting custody and/or liability of thedevices.

Accordingly, in embodiments, devices may be registered by themanufacturers 139132 with the registry 1129 prior to shipping of theunits of vaccine. Once the devices are registered, the registry 1129 maycatalogue/record the identification values and make the devices visibleto entities within the supply chain, e.g., approved entities may checkthe status of the devices via one or more interfaces as describedherein. A shipping company, prior to taking custody and/or acceptingliability of the units of vaccine, may query the registry 1129 to verifythat the one or more devices tracking the units of vaccine areregistered and/or were registered by the manufacturers 139132. Theshipping company may also verify one or more attributes of the devices,e.g., GPS location, temperature, pressure, etc. Upon verifying thedevices as being properly registered and owned/assigned to themanufacturer, the shipping company, e.g., airplane 139114, may thenaccept custody and/or liability of the received units. The manufacturers139132 and/or the shipping company 139114 may then update thecorresponding records 1131 (FIG. 1) via sending one or more devicestatus values 6114 (FIG. 6), registration requests 6112, device eventmessages 6116, and/or other types of messages, as described herein. Inembodiments, the registry 1129 may check to ensure that the receivingentity is authorized to accept the units of the vaccine. Thedistribution center 139116 may then verify, via the registry 1129, thateach of the devices is owned and/or otherwise assigned to the shippingcompany before taking custody of the units of vaccine. Upon acceptanceof the units of vaccine, the distribution center 139116 may then updatethe corresponding records 1152 via sending one or more device statusvalues 6114, registration requests 6112, device event message 6116,and/or other types of messages as described herein. Such verificationand transfers of ownership may be completed at each exchange point inthe supply line.

In embodiments, the registry 1129 may detect a discrepancy indicative ofan unusual event within the supply chain, e.g., via a sentry, asdescribed herein. For example, the number of units of vaccine known tobe released from the distribution center 139116 may be different thanthe number of units of vaccine received by the hospital 139120. Theregistry 1129 may send an alert message to one or more of themanufacturer 139132, distribution center 139116, and/or shippingcompanies, e.g., airplane 139114 and/or truck 139118, used to transportthe units of vaccine from the manufacturer 139132 to the hospital139120. Such an unusual event may be the result of a truck 139126getting lost and/or not completing delivery of the vaccine to thehospital 139120. In certain aspects, the registry 1129 may detectunusual events based on discrepancies within a device's lifecycle and/orattributes.

While the foregoing examples concerned embodiments of the registry 1129in the context of a vaccine supply chain, it is to be understood thatembodiments of the registry 1129 may be used in other types of supplychains, e.g., food, gas, consumer goods, etc., and/or any other type ofmanufacturing process or environment where devices are utilized. Forexample, embodiments of the current disclosure may involve a smartthermostat installed in a living room. As will be understood, the smartthermostat may have a serial number (physical ID), a WiFi MAC address(network ID) used to connect to a WiFi network, and/or a humanunderstandable ID such as “Living Room Stat” (meta-ID or service ID, asdisclosed herein). In certain aspects, embodiments of the currentdisclosure provide for an enterprise and/or service provider to managethe identities and/or life cycles of thousands of such devices.

Embodiments of the current disclosure may integrate with atelecommunications number registry, such a Toll-Free Management Platform(TFMP).

Embodiments of the registry 1129, as disclosed herein, may provide for acomprehensive IoT machine identity lifecycle management, e.g., “cradleto grave”, using identities sourced from trusted partners/manufacturersof devices, as disclosed herein.

Embodiments of the registry 1129 and/or the SPGs, as disclosed herein,may improve the problems associated with security fragmentation causedby multiple device IDs, data management, and governance. For example,some embodiments of the current disclosure may provide for a centralizedand scalable machine identity, e.g., IoT UID 6118, registry coupled witha SPG-based management, that may be agnostic to use case, platform,network and industry vertical.

The seed of trust, provided by embodiments of the current disclosure,may provide for more granular identity and context information, whichmay enable incremental services and facilitate device troubleshootingand management.

As disclosed herein, some embodiments of the current disclosure mayenable a computer system and/or mobile device manager to quicklyidentify devices that may be compromised, at risk of being compromised,and/or associated with fraud for purposes of quarantining such devices.

Embodiments of the current disclosure may provide for a chipset/modulemanufacturer and/or manufacturers further down a device assembly processto: trace components across one or more owners which may provide forpremium positioning, improve product support, and/or confirm deviceactivation. Embodiments of the current disclosure may provide for achipset/module manufacturer to: receive traceable notifications, receiveupdate confirmations, recycle IoT UIDs and/or other types of deviceidentifiers, and/or the like. As will be appreciated, an IoT deviceregistrar, as disclosed herein, may collect device events from multiplesources and/or environments and present them in a manageable and easilyunderstandable interface, e.g., a SPG. Embodiments of the IoT deviceregistrar, as disclosed herein, may provide for easy retrieval of adevices current owner, location, jurisdiction, and the like. Embodimentsof the IoT device registrar, as disclosed herein, may provide for userand/or manufacturers of devices to retire devices and be relativelyconfident that such devices will not be used to produce rouge devicescapable of infiltrating a system. Accordingly, some embodiments of thecurrent disclosure may mitigate the risk of a registered device beingcounterfeited. Embodiments of the current disclosure may provide forsecure provisioning of devices into a corporate enterprise environmentand subsequent managing of their identities. Embodiments of the IoTdevice registry, as disclosed herein, may provide for trustedidentification between devices, via the IoT UIDs, which, in turn, maymitigate and/or prevent malware downloads.

Embodiments of the current disclosure may also provide for a neutralsteward, e.g., the registry 1129, for managing and verifying devices. Incertain aspects, the registry 1129 may provide for attestation of aregistered device, thereby providing for trusted interactions betweenentities and registered devices. In certain aspects, a first device mayverify and/or authenticate itself to a second device based at least inpart on the registry 1129, e.g., some embodiments of the currentdisclosure provide for one-way authentication. In certain aspects, twodevices may verify/authenticate themselves to each other via theregistry 1129, e.g., two-way authentication. In certain aspects, theregistry may provide for distributed authentication of devices. Incertain aspects, the registry 1129 may serve as a centralizedauthentication authority and/or trusted third party that managesauthentication certificates. In embodiments, the registry 1129 mayimplement and/or facilitate implementation of one or more protocolsbased, as least in part, on the National Institute of Standards andTechnology (NIST) Interagency or Internal Reports (NISTR) “NISTIR 8259”.For example, the registry 1129 may enable the device to signal tonetworks (that the device wishes to join) information such as the typeof device, what type of access is being requested, required networkfunctionality, provisioned credentials, etc. In certain aspects, theregistry 1129 may implement one or more protocols based at least in parton the DNS-based Authentication of Named Entities (DANE) standard.Non-limiting examples include defining bindings between a domain nameproviding a particular service and a key that can be used to establishencrypted connections to that service. In certain aspects, the registry1129 may implement one or more protocols based at least in part on theManufacturer Usage Description (MUD) standard, e.g., methods for adevice to signal to a network its type, approved access, requiredfunctionality, etc. In certain embodiments, the registry 1129 mayimplement one or more protocols based at least in part on the TypeAllocation Code (TAC) standard. In embodiments, the registry 1129 mayintegrate and/or support a Network of Things based infrastructure.

Embodiments of the current disclosure may provide for a method formanaging network connected devices. The method incudes interpreting, ata server, a device registration value that includes a deviceidentification value and an owner identification value. The deviceidentification value corresponds to at least one of the networkconnected devices. The owner identification value corresponds to anowner of the at least one network connected device. The method furtherincludes storing, in a database via the server, the deviceidentification value in a record corresponding to the owneridentification value. The method further includes interpreting, at theserver, a device status value that includes the device identificationvalue and a device attribute value. The device attribute valuecorresponds to an attribute of the at least one network connecteddevice. The method further includes identifying, via the server, therecord storing the device identification value. The method furtherincludes modifying, via the server, a field of the record based at leastin part on the device attribute value. In certain aspects, the attributevalue corresponds to a status of the at least one network connecteddevice. In certain aspects, the status is at least one of: provisioned;active; malfunctioning; suspended; decommissioned; missing; compromised;or unknown. In certain aspects, the attribute value corresponds to atleast one of: a location; a temperature; a pressure; a force; or a seal.In certain aspects, the attribute value corresponds to the location andthe location corresponds to a product supply chain. In certain aspects,the method further includes verifying, via the server, that at least oneof the device registration value or the device status value wasgenerated by an authorized entity. In certain aspects, the authorizedentity is the owner of the at least one network connected device. Incertain aspects, the authorized entity is a manufacturer of the at leastone network connected device. In certain aspects, the method furtherincludes establishing a seed of trust between the server and an entitythat generated at least one of the device registration value or thedevice status value. In certain aspects, establishing the seed of trustoccurs prior to interpreting the device registration value. In certainaspects, the device registration value corresponds to a change inownership of the at least one network connected device. In certainaspects, the method further includes: detecting, via the server andbased at least in part on at least one of the device registration valueor the device status value, an unusual event corresponding to the atleast one network connected device; and transmitting an alert messagecorresponding to the unusual event.

Embodiments of the current disclosure may provide for a system formanaging network connected devices. The system includes a server havingat least one processor; and a memory device. The memory device isstructured to store a plurality of records, each record of the pluralitycorresponding to an owner of at least one of the network connecteddevices. The at least one processor is structured to: interpret a deviceregistration value that includes a device identification value and anowner identification value, the device identification valuecorresponding to at least one of the network connected devices and theowner identification value corresponding to an owner of the at least onenetwork connected device. The at least one processor is structured tostore, in the memory device, the device identification value in a recordof the plurality of records, the record corresponding to the owneridentification value. The at least one processor is structured tointerpret a device status value that includes the device identificationvalue and a device attribute value, the device attribute valuecorresponding to an attribute of the at least one network connecteddevice. The at least one processor is structured to identify, based atleast in part on the device identification value, the record. The atleast one processor is structured to modify a field of the record basedat least in part on the device attribute value.

Embodiments of the current disclosure may provide for an apparatus formanaging network connected devices. The apparatus includes a deviceregistration circuit structured to: interpret a device registrationvalue that includes a device identification value and an owneridentification value, the device identification value corresponding toat least one of the network connected devices and the owneridentification value corresponding to an owner of the at least onenetwork connected device; and store, in a database, the deviceidentification value in a record corresponding to the owneridentification value. The apparatus further includes a device statusmodification circuit structured to: interpret a device status value thatincludes the device identification value and a device attribute value,the device attribute value corresponding to an attribute of the at leastone network connected device; identify, based at least in part on thedevice identification value, the record storing the deviceidentification value; and modify a field of the record based at least inpart on the device attribute.

Embodiments of the current disclosure may provide for a non-transitorycomputer readable medium storing instructions. The stored instructionsadapt at least one processor to interpret a device registration valuethat includes a device identification value and an owner identificationvalue, the device identification value corresponding to at least one ofa plurality of network connected devices and the owner identificationvalue corresponding to an owner of the at least one network connecteddevice. The stored instructions further adapt the at least one processorto store, in a database, the device identification value in a recordcorresponding to the owner identification value. The stored instructionsfurther adapt the at least one processor to interpret a device statusvalue that includes the device identification value and a deviceattribute value. The device attribute value corresponds to an attributeof the at least one network connected device. The stored instructionsfurther adapt the at least one processor to identify the record storingthe device identification value; and modify a field of the record basedat least in part on the device attribute value.

An example method includes interpreting, via an IoT UID processingcircuit, an IoT UID and device property data; associating, via a recordmanagement circuit, the IoT UID with the device property data via arecord; and transmitting, via a record provisioning circuit, the record.

Certain further aspects of the example method are described following,any one or more of which may be present in certain embodiments. Themethod further including storing the record in a database. The deviceproperty data includes an owner identifier value. The device propertydata includes a manufacturer identifier value. The device property dataincludes at least one of: a trusted platform module key; a media accesscontrol address; a software version identifier; or a firmwareidentifier. The wherein associating the IoT UID with the device propertydata via a record comprises: including at least one of the IoT UID andthe device property data in the record. The method further includingidentifying the record in a database, based at least in part on the IoTUID. The method further including: polling, via an update managementcircuit, an external data source to identify changes to a devicecorresponding to the device property data; and updating, via the recordmanagement circuit, the record to reflect the changes. The deviceproperty data indicates that a corresponding device is a Greenfielddevice; and associating, the IoT UID with the device property data viathe record comprises including an identifier in the record thatindicates the device is a Greenfield device. The device property dataindicates that a corresponding device is a Brownfield device; andassociating, the IoT UID with the device property data via the recordcomprises including an identifier in the record that indicates thedevice is a Brownfield device. The record includes a trust indicator fora device associated with the IoT UID. The trust indicator is a numericvalue. The trust indicator is an enumerated type. The method furtherincluding interpreting a device event message and updating a record inan IoT device registry based at least in part on the device eventmessage.

An example apparatus includes an IoT UID processing circuit structuredto interpret an IoT UID and device property data; a record managementcircuit structured to associate the IoT UID with the device propertydata via a record; and a record provisioning circuit structured totransmit the record.

Certain further aspects of the example apparatus are describedfollowing, any one or more of which may be present in certainembodiments. The device property data includes an owner identifiervalue. The device property data includes a manufacturer identifiervalue. The device property data includes at least one of: a trustedplatform module key; a media access control address; a software versionidentifier; or a firmware identifier. The record management circuit isfurther structured to include at least one of the IoT UID and the devicedata in the record. The record management circuit is further structuredto identify the record in a database, based at least in part on the IoTUID. The apparatus further including an update management circuitstructured to: poll an external data source to identify changes to adevice corresponding to the device property data; and update the recordto reflect the changes. The device property data indicates that acorresponding device is a Greenfield device; and the record managementcircuit is further structured to include an identifier in the recordthat indicates the IoT device is a Greenfield device. The deviceproperty data indicates that a corresponding device is a Brownfielddevice; and the record management circuit is further structured toinclude an identifier in the record that indicates the IoT device is aBrownfield device. The record includes a trust indicator for a deviceassociated with the IoT UID. The trust indicator is a numeric value. Thetrust indicator is an enumerated type.

An example method includes interpreting, via an IoT UID processingcircuit, an IoT UID; generating, via a device lookup circuit, a querythat includes the IoT UID and is structured to retrieve device propertydata corresponding to the IoT UID; and transmitting, via a queryprovisioning circuit, the query to an IoT device registrar server.

Certain further aspects of the example method are described following,any one or more of which may be present in certain embodiments. Themethod further including interpreting, via a device property dataprocessing circuit, the device property data retrieved by the query. Thedevice property data includes an owner identifier value. The deviceproperty data includes a manufacturer identifier value. The deviceproperty data includes at least one of a trusted platform module key; amedia access control address; a software version identifier; or afirmware identifier. The device property data includes a trust indicatorfor a device associated with the IoT UID. The method further includingdisplaying, an electronic device, the trust indicator. The trustindicator is a numeric value. The trust indicator is an enumerated type.The method further including denying the device associated with the IoTUID access to another device, based at least in part on the trustindicator. The method further including granting the device associatedwith the IoT UID access to another device, based at least in part on thetrust indicator.

An example apparatus includes an IoT UID processing circuit structuredto interpret an IoT UID; a device lookup circuit structured to: generatea query that includes the IoT UID; and retrieve device property datacorresponding to the IoT UID; and a query provisioning circuitstructured to transmit the query to an IoT device registrar server.

Certain further aspects of the example apparatus are describedfollowing, any one or more of which may be present in certainembodiments. The apparatus further including a device property dataprocessing circuit structured to interpret the device property dataretrieved by the query. The device property data includes an owneridentifier value. The device property data includes a manufactureridentifier value. The device property data includes at least one of atrusted platform module key; a media access control address; a softwareversion identifier; or a firmware identifier. The device property dataincludes a trust indicator for a device associated with the IoT UID. Thetrust indicator is a numeric value. The trust indicator is an enumeratedtype. The apparatus further including a gatekeeping circuit structuredto deny the device associated with the IoT UID access to another device,based at least in part on the trust indicator. The apparatus furtherincluding a gate keeping circuit structured to grant the deviceassociated with the IoT UID access to another device, based at least inpart on the trust indicator.

An example method includes interpreting, via a user input processingcircuit, one or more user input command values; determining, via anInternet of Things Universal Identification (IoT UID) identificationcircuit, one or more IoT UIDs, based at least in part on the one or moreuser input command values; generating, via a device lookup circuit, aquery that includes the one or more IoT UIDs; retrieving, via the devicelookup circuit, device property data corresponding to the one or moreIoT UIDs; transmitting, via a query provisioning circuit, the query toan IoT device registrar server; interpreting, via a device propertyprocessing circuit, the device property data generated by the IoT UIDregistrar server in response to the query; and displaying, via a displaycircuit, the device property data with the corresponding one or more IoTUIDs.

Certain further aspects of the example method are described following,any one or more of which may be present in certain embodiments. The oneor more user input command values include the one or more IoT UIDs. Theone or more user input command values include credentials. Thedetermining the one or more IoT UIDs is based at least in part on thecredentials. The method further including filtering data in the deviceproperty data, based at least in part on the one or more user inputcommand values. The filtered data relates to historical ownership of adevice corresponding to one of the IoT UIDs. The device property dataincludes a patch status for a device of the corresponding IoT UID. Thedevice property data includes a security risk analysis value for adevice of the corresponding IoT UID. The method further includinggenerating a security alert, based at least in part on the security riskanalysis value. The device property data includes a trust level valuefor a device of the corresponding IoT UID. The method further includinggenerating a security alert, based at least in part on the trust levelvalue. The method further including generating and tracking a patchingcampaign for devices corresponding to one or more IoT UIDs. The methodfurther including interpreting a device event message and updating arecord in an IoT device registry based at least in part on the deviceevent message.

An example apparatus includes a user input processing circuit structuredto interpret one or more user input command values; an Internet ofThings Universal Identification (IoT UID) identification circuitstructured to determine one or more IoT UIDs, based at least in part onthe one or more user input command values; a device lookup circuitstructured to: generate a query that includes the one or more IoT UIDs;and retrieve device property data corresponding to the one or more IoTUIDs; a query provisioning circuit structured to transmit the query toan IoT device registrar server; a device property processing circuitstructured to interpret the device property data generated by the IoTdevice registrar server in response to the query; and a display circuitstructured to display the device property data with the correspondingone or more IoT UIDs.

Certain further aspects of the example apparatus are describedfollowing, any one or more of which may be present in certainembodiments. The user input command values include the one or more IoTUIDs. The user input command values include credentials. The IoT UIDidentification circuit is further structured to determine the one ormore IoT UIDs, based at least in part on the credentials. The apparatusfurther including a filtering circuit structured to filter data in thedevice property data, based at least in part on the one or more userinput command values. The filtered data relates to historical ownershipof a device corresponding to one of the IoT UIDs. The device propertydata includes a patch status for a device of the corresponding IoT UID.The device property data includes a security risk analysis value for adevice of the corresponding IoT UID. The apparatus further including asecurity alert circuit structured to generate a security alert, based atleast in part on the security risk analysis value. The device propertydata includes a trust level value for a device of the corresponding IoTUID. The apparatus further including a security alert circuit structuredto generate a security alert, based at least in part on the trust levelvalue. The apparatus further including a patching campaign circuitstructured to generate and track a patching campaign for devicescorresponding to one or more IoT UIDs.

An example system includes an Internet of Things (IoT) device registrarserver structured to provide access to an IoT device registry; and adevice management server structured to: communicate with the IoT deviceregistrar server; and provide a graphical user interface structured todisplay device property data for one or more devices registered with theIoT device registry, wherein the device property data is retrieved bythe graphical user interface from the IoT device registry via queryingthe IoT device registrar server.

Certain further aspects of the example system are described following,any one or more of which may be present in certain embodiments. Each ofthe one or more devices has a corresponding IoT Universal Identification(UID) associated with the device. The system further including afiltering circuit, in communication with the device management server,structured to filter data in the device property data. The filtered datarelates to historical ownership of a device having an IoT UID associatedwith the device. The device property data includes a patch status for adevice having an IoT UID associated with the device. The device propertydata includes a security risk analysis value for a device of thecorresponding IoT UID. The system further including, in communicationwith the device management server, a security alert circuit structuredto generate a security alert, based at least in part on the securityrisk analysis value. The device property data includes a trust levelvalue for a device of the corresponding IoT UID. The system furtherincluding a security alert circuit, in communication with the devicemanagement server, structured to generate a security alert, based atleast in part on the trust level value. The system further including apatching campaign circuit, in communication with the device managementserver, structured to generate and track a patching campaign for devicescorresponding to one or more IoT UIDs. The system further including acredential verification circuit, in communication with the devicemanagement server, structured to: determine whether a user of thegraphical user interface is authorized to access the device propertydata for the one or more devices; and if it is determined that the userof the graphical user interface is not authorized to access the deviceproperty data for the one or more devices, restrict the display of thedevice property data for one or more devices.

An example apparatus includes at least one processor; and a memorydevice storing an application structured to adapt the at least oneprocessor to generate a graphical user interface structured to: receiveone or more user input command values; determine, based at least in parton the one or more user input command values, one or more devicesregistered with an IoT device registry via corresponding Internet ofThings Universal Identifications (IoT UIDs); and display property datafor the one or more devices.

Certain further aspects of the example apparatus are describedfollowing, any one or more of which may be present in certainembodiments. The one or more user input command values include the oneor more IoT UIDs. The one or more user input command values includecredentials. The application stored in the memory device is furtherstructured to adapt the at least one processor to determine the one ormore IoT UIDs, based at least in part on the credentials. Theapplication stored in the memory device is further structured to adaptthe at least one processor to filter data in the device property data,based at least in part on the one or more user input command values. Thefiltered data relates to historical ownership of a device correspondingto one of the IoT UIDs. The device property data includes a patch statusfor a device of the corresponding IoT UID. The device property dataincludes a security risk analysis value for a device of thecorresponding IoT UID. The application stored in the memory device isfurther structured to adapt the at least one processor to: generate asecurity alert, based at least in part on the security risk analysisvalue; and provide the security alert to the graphical user interface tobe displayed by the graphical user interface. The device property dataincludes a trust level value for a device of the corresponding IoT UID.The application stored in the memory device is further structured toadapt the at least one processor to: generate a security alert, based atleast in part on the trust level value; and provide the security alertto the graphical user interface to be displayed by the graphical userinterface. The application stored in the memory device is furtherstructured to adapt the at least one processor to: generate and track apatching campaign for devices corresponding to one or more IoT UIDs; andprovide information about the patching campaign to the graphical userinterface to be displayed by the graphical user interface.

An example method includes generating, via at least one processor, agraphical user interface structured to: receive one or more user inputcommand values; and communicate with an Internet of Things (IoT) deviceregistrar server; receiving, via the graphical user interface, the oneor more user input command values; determining, via the at least oneprocessor, one or more devices registered with an IoT device registryvia querying the IoT device registrar server, based at least in part onthe one or more user input command values; and displaying deviceproperty data for the one or more devices received in response toquerying the IoT device registrar server.

Certain further aspects of the example method are described following,any one or more of which may be present in certain embodiments. Each ofthe one or more devices has a corresponding IoT Universal Identification(UID) associated with the device. The method further including filteringdata in the device property data. The filtered data relates tohistorical ownership of a device having an IoT UID associated with thedevice. The device property data includes a patch status for a devicehaving an IoT UID associated with the device. The device property dataincludes a security risk analysis value for a device of thecorresponding IoT UID. The method further including: generating asecurity alert, based at least in part on the security risk analysisvalue; and displaying the security alert on a same display as the deviceproperty data. The device property data includes a trust level value fora device of the corresponding IoT UID. The method further including:generating a security alert, based at least in part on the trust levelvalue; and displaying the security alert on a same display as the deviceproperty data. The method further including: generating and tracking apatching campaign for devices corresponding to one or more IoT UIDs; anddisplaying information about the patching campaign on a same display asthe device property data. The method further including determiningwhether a user of the graphical user interface is authorized to accessthe device property data for the one or more devices; and if it isdetermined that the user of the graphical user interface is notauthorized to access the device property data for the one or moredevices, restricting the display of the device property data for one ormore devices.

An example apparatus includes a single pane of glass (SPG) interfacecircuit structured to interpret an Internet of Things UniversalIdentification (IoT UID) received from an SPG; and a record managementcircuit structured to retrieve device property data corresponding to theIoT UID, wherein the SPG interface circuit is further structured totransmit the device property data to the SPG.

Certain further aspects of the example apparatus are describedfollowing, any one or more of which may be present in certainembodiments. The IoT UID and device property data are associated with adevice. The apparatus further including a filtering circuit, incommunication with the record management circuit, structured to filterdata in the device property data. The filtered data relates tohistorical ownership of the device. The device property data includes apatch status for the device. The device property data includes asecurity risk analysis value for the device. The apparatus furtherincluding, in communication with the record management circuit, asecurity alert circuit structured to: generate a security alert, basedat least in part on the security risk analysis value; and provide thesecurity alert to the SPG interface circuit to be displayed by the SPG.The device property data includes a trust level value for a device ofthe corresponding IoT UID. The apparatus further including a securityalert circuit, in communication with the record management circuit,structured to: generate a security alert, based at least in part on thetrust level value; and provide the security alert to the SPG interfacecircuit to be displayed by the SPG. The apparatus further including apatching campaign circuit, in communication with the record managementcircuit, structured to generate and track a patching campaign fordevices corresponding to one or more IoT UIDs; and provide informationabout the patching campaign to the SPG interface circuit to be displayedby the SPG. The apparatus further including a credential verificationcircuit, in communication with the record management circuit, structuredto: determine whether a user of the SPG is authorized to access thedevice property data corresponding to the IoT UID; and if it isdetermined that the user of the SPG is not authorized to access thedevice property data, restrict display of the device property data onthe SPG.

An example method includes identifying one or more Brownfield devices;generating device property data, based at least in part on the one ormore Brownfield devices; transmitting, to an Internet of Things (IoT)device registrar server, a registration request that includes the deviceproperty data; interpreting one or more Internet of Things UniversalIdentifications (IoT UIDs) generated in response to the transmitting ofthe registration request; and embedding the one or more IoT UIDs in theone or more Brownfield devices.

Certain further aspects of the example method are described following,any one or more of which may be present in certain embodiments.Embedding the one or more IoT UIDs in the one or more Brownfield devicescomprises piggybacking the one or more IoT UIDs off one or more basemessages transmitted to the one or more Brownfield devices. The one ormore base messages are part of at least one of a software update or afirmware update for the one or more Brownfield devices. The one or morebase messages are transmitted to the one or more Brownfield devices atone or more scheduled times. The one or more base messages aretransmitted in response to the one or more Brownfield devices polling amanagement device platform. Embedding the one or more IoT UIDs in theone or more Brownfield devices comprises: for each of the one or moreBrownfield devices, storing a corresponding one of the IoT UIDs in amemory device of the Brownfield device. Embedding the one or more IoTUIDs in the one or more Brownfield devices comprises: for each of theone or more Brownfield devices, installing a component into theBrownfield device, wherein the component includes the IoT UID. Themethod further including associating each of one or more portions of thedevice property data with a distinct IoT UID of the one or more IoT UIDsin an IoT UID device registry, wherein each of the one or more portionsof the device property data corresponds to a distinct one of the one ormore Brownfield devices. At least one of the following is performed, inpart, using a single pane of glass (SPG): identifying the one or moreBrownfield devices; generating the device property data; transmittingthe registration request; or interpreting the one or more IoT UIDsgenerated in response to the transmitting of the registration request.The SPG is an application programing interface. The SPG is a graphicaluser interface. The SPG is hosted by and/or integrated into a devicemanagement platform. The SPG is hosted by an IoT device registrar. Themethod further including transmitting a confirmation message thatindicates the one or more IoT UIDs were embedded in the one or moreBrownfield devices. The device property data includes one or more owneridentifier values, each of the one or more owner identifier valuescorresponding to an owner of the one or more Brownfield devices. Thedevice property data includes one or more manufacturer identifiervalues, each of the one or more manufacturer identifier valuescorresponding to a manufacturer of the one or more Brownfield devices.The device property data includes at least one of a trusted platformmodule (TPM) key; a media access control (MAC) address; or amanufacturing serial number. The method further including transmitting aset of credentials to the IoT device registrar server, wherein the setof credentials provides authorization to register the one or moreBrownfield devices with an IoT device registry associated with the IoTdevice registrar server. The set of credentials is based at least inpart on a public key encryption infrastructure (PKI). The method furtherincluding interpreting a device event message and updating a record inan IoT device registry based at least in part on the device eventmessage.

An example apparatus includes a display circuit structured to generate agraphical user interface (GUI) configured to receive one or more userinput command values corresponding to device property data for one ormore Brownfield devices; a requestor circuit structured to generate aregistration request that includes the device property data; a requestprovisioning circuit structured to transmit the registration request toan Internet of Things (IoT) device registrar server; an Internet ofThings Universal Identification (IoT UID) processing circuit structuredto interpret one or more IoT UIDs generated by the IoT device registrarserver in response to the registration request; and an IoT UIDprovisioning circuit structured to at least one of: transmit the one ormore IoT UIDs; or display the one or more IoT UIDs on an electronicdisplay.

Certain further aspects of the example apparatus are describedfollowing, any one or more of which may be present in certainembodiments. The apparatus further including an embedding verificationcircuit structured to interpret embedding confirmation data indicatingthat the one or more IoT UIDs were embedded into the one or moreBrownfield devices; and transmit one or more confirmation messagesindicating that the one or more IoT UIDs were embedded into the one ormore Brownfield devices. The transmission of the one or moreconfirmation messages is to the display circuit; and the display circuitis further structured to display the embedding confirmation data in theGUI. The device property data includes one or more owner identifiervalues, each of the one or more owner identifier values corresponding toan owner of the one or more Brownfield devices. The device property dataincludes one or more manufacturer identifier values, each of the one ormore manufacturer identifier values corresponding to a manufacturer ofthe one or more Brownfield devices. The device property data includes atleast one of a trusted platform module (TPM) key; a media access control(MAC) address; or a manufacturing serial number. The apparatus furtherincluding a credential circuit structured to interpret a set ofcredentials corresponding to a user of the GUI; and transmit the set ofcredentials to the IoT device registrar server, wherein the set ofcredentials provides authorization to register the one or moreBrownfield devices with an IoT device registry associated with the IoTdevice registrar server. The IoT UID provisioning circuit is structuredto transmit the one or more IoT UIDs via piggybacking the one or moreIoT UIDs off of one or more base messages transmitted to the one or moreBrownfield devices. The one or more base messages are part of at leastone of a software update or a firmware update for the one or moreBrownfield devices. The one or more base messages are transmitted to theone or more Brownfield devices at one or more scheduled times. The oneor more base messages are transmitted in response to the one or moreBrownfield devices polling a management device platform. At least one ofthe display circuit, the requestor circuit, the request provisioningcircuit, the IoT UID processing circuit, or the IoT UID provisioningcircuit form part of a device management platform.

An example method includes interpreting, via a device registrationrequest circuit, a registration request that maps device property datato one or more Brownfield devices; generating, via an Internet of ThingsUniversal Identification (IoT UID) generation circuit, based at least inpart on the registration request, an IoT UID for each of the one or moreBrownfield devices; and transmitting, via an IoT UID provisioningcircuit, the IoT UID for each of the one or more Brownfield devices.

Certain further aspects of the example method are described following,any one or more of which may be present in certain embodiments. Themethod further including interpreting one or more conformation messagesindicating that the one or more IoT UIDs were embedded into the one ormore Brownfield devices. The method further including associating, basedat least in part on the mapping of device property data to the one ormore Brownfield devices, each of one or more portions of the deviceproperty data with a distinct IoT UID of the one or more IoT UIDs in anIoT UID device registry. The method further including generating a trustlevel value for each of the one or more Brownfield devices; andtransmitting the trust level values. Each of the trust level values forthe one or more Brownfield devices has an initial value indicating thatthe corresponding Brownfield device is less trustworthy than acomparable Greenfield device.

An example method includes interpreting, via a request processingcircuit, a registration request that includes device property data forone or more Brownfield devices; generating, via an Internet of ThingsUniversal Identification (IoT UID) generation circuit, one or more IoTUIDs, based at least in part on the device property data; associating,via a record management circuit, each of the one or more IoT UIDs withat least some of the device property data via a record; transmitting,via an IoT UID provisioning circuit, the one or more IoT UIDs; andinterpreting, via a registration confirmation circuit, one or moreembedding confirmation messages generated in response to transmittingthe IoT UIDs, wherein the one or more embedding confirmation messagesindicate embedding of the one or more IoT UIDs into the one or moreBrownfield devices.

Certain further aspects of the example method are described following,any one or more of which may be present in certain embodiments. Thedevice property data includes one or more owner identifier values, eachof the one or more owner identifier values corresponding to an owner ofthe one or more Brownfield devices.

An example apparatus includes a request processing circuit structured tointerpret a registration request that includes device property data forone or more Brownfield devices; an Internet of Things UniversalIdentification (IoT UID) generation circuit structured to generate oneor more IoT UIDs, based at least in part on the device property data; arecord management circuit structured to associate each of the one ormore IoT UIDs with at least some of the device property data via arecord; an IoT UID provisioning circuit structured to transmit the oneor more IoT UIDs; and a registration confirmation circuit structured tointerpret one or more embedding confirmation messages generated inresponse to transmitting the IoT UIDs; wherein the one or more embeddingconfirmation messages indicate embedding of the one or more IoT UIDsinto the one or more Brownfield devices.

Certain further aspects of the example apparatus are describedfollowing, any one or more of which may be present in certainembodiments. The device property data includes one or more manufactureridentifier values, each of the one or more manufacturer identifiervalues corresponding to a manufacturer of the one or more Brownfielddevices.

An example method includes manufacturing one or more Greenfield devices;generating device property data based at least in part on the one ormore Greenfield devices; transmitting, to an Internet of Things (IoT)device registrar server, a registration request that includes the deviceproperty data; interpreting one or more Internet of Things UniversalIdentifiers (IoT UIDs) generated in response to the transmitting of theregistration request; and embedding the one or more IoT UIDs in the oneor more Greenfield devices.

Certain further aspects of the example method are described following,any one or more of which may be present in certain embodiments. At leastone of generating the device property data and transmitting the deviceproperty data forms part of a bootstrapping process. The bootstrappingprocess is initiated at least in part by the one or more Greenfielddevices. The method further including verifying that the one or moreGreenfield devices are authorized to transmit the device property datato the IoT device registrar. Verifying the one or more Greenfielddevices is based at least in part on a cryptographic key. Thecryptographic key is based at least in part on a public keyinfrastructure (PKI). At least one of generating the device propertydata or transmitting the device property data is performed via a devicemanagement platform. The device management platform comprises a singlepane of glass (SPG). The device property data includes at least one ofan owner identifier value; a manufacturer identifier value; a TrustedPlatform Module (TPM) Key; a Media Access Control (MAC) address; or amanufacturing serial number. Embedding the one or more IoT UIDs into theone or more Greenfield devices comprises: storing the one or more IoTUIDs in one or more memory locations of the one or more Greenfielddevices. Embedding the one or more IoT UIDs into the one or moreGreenfield devices comprises installing one or more components into theone or more Greenfield device. The one or more components include theone or more IoT UIDs. Embedding the one or more IoT UIDs in the one ormore Greenfield devices occurs prior to a sale of the one or moreGreenfield devices. Embedding the one or more IoT UIDs in the one ormore Greenfield devices occurs after a sale of the one or moreGreenfield devices. The method further including interpreting a deviceevent message and updating a record in an IoT device registry based atleast in part on the device event message.

An example method includes obtaining a Greenfield device; generatingdevice property data corresponding to the Greenfield device;transmitting the device property data to an Internet of Things (IoT)device registrar server; interpreting an Internet of Things UniversalIdentifier (IoT UID) generated by the IoT device registrar server inresponse to the device property data; and embedding the IoT UID into theGreenfield device.

Certain further aspects of the example method are described following,any one or more of which may be present in certain embodiments. At leastone of generating the device property data and transmitting the deviceproperty data forms part of a bootstrapping process. The bootstrappingprocess is initiated at least in part by the Greenfield device. Themethod further including verifying that the Greenfield device isauthorized to transmit the device property data to the IoT deviceregistrar. Verifying the Greenfield device is based at least in part ona cryptographic key. The cryptographic key is based at least in part ona public key infrastructure (PKI). At least one of generating the deviceproperty data or transmitting the device property data is performed viaa device management platform. The device management platform comprises asingle pane of glass (SPG). The device property data includes at leastone of an owner identifier value; a manufacturer identifier value; aTrusted Platform Module (TPM) Key; a Media Access Control (MAC) address;or a manufacturing serial number. Embedding the IoT UID into theGreenfield device comprises storing the IoT UID in a location of theGreenfield device. Embedding the IoT UID into the Greenfield deviceincludes: installing a component into the Greenfield device. Thecomponent includes the IoT UID. Embedding the IoT UID in the Greenfielddevice occurs prior to a sale of the Greenfield device. Embedding theIoT UID in the Greenfield device occurs after a sale of the Greenfielddevice.

An example system includes one or more manufacturing componentsstructured to manufacture at least a portion of a Greenfield device; adevice management platform structured to generate device property datacorresponding to the Greenfield device; transmit the device propertydata to an Internet of Things (IoT) device registrar server; andinterpret an Internet of Things Universal Identifier (IoT UID) generatedby the IoT device registrar server in response to the device propertydata; and an embedding tool structured to embed the IoT UID into theGreenfield device.

Certain further aspects of the example system are described following,any one or more of which may be present in certain embodiments. Thedevice property data includes at least one of an owner identifier value;a manufacturer identifier value; a Trusted Platform Module (TPM) Key; aMedia Access Control (MAC) address; or a manufacturing serial number.

An example apparatus includes device property data; a memory device; anda bootstrapping circuit structured to: initiate a request for anInternet of Things Universal Identifier (IoT UID) from an IoT deviceregistrar server, the request including the device property data;transmit the request; interpret an IoT UID generated in response to therequest; and store the IoT UID in the memory device.

Certain further aspects of the example apparatus are describedfollowing, any one or more of which may be present in certainembodiments. The device property data includes at least one of an owneridentifier value; a manufacturer identifier value; a Trusted PlatformModule (TPM) Key; a Media Access Control (MAC) address; or amanufacturing serial number. The apparatus further including acredential circuit structured to transmit one or more credentials thatdemonstrate authorization to register the apparatus with an IoT deviceregistrar. The one or more credentials are cryptographic keys. Thecryptographic keys are public encryption key infrastructure (PKI) keys.

An example method includes powering-on a Greenfield device; andinitiating a bootstrapping process on the Greenfield device structuredto: register the Greenfield device with an Internet of Things (IoT)device registrar; and embed an Internet of Things Universal Identifier(IoT UID) issued by the IoT device registrar as part of registering theGreenfield device.

Certain further aspects of the example method are described following,any one or more of which may be present in certain embodiments.Registration of the Greenfield device with the IoT device registrar isbased at least in part on device property data that includes at leastone of an owner identifier value; a manufacturer identifier value; aTrusted Platform Module (TPM) Key; a Media Access Control (MAC) address;or a manufacturing serial number. Powering-on the Greenfield deviceoccurs prior to a first sale of the Greenfield device. Powering-on ofthe Greenfield device is performed by a first owner of the Greenfielddevice.

An example method includes interpreting, via a device registrationrequest circuit, a registration request that maps device property datato one or more Greenfield devices; generating, via an Internet of ThingsUniversal Identifier (IoT UID) generation circuit, based at least inpart on the registration request, an IoT UID for each of the one or moreGreenfield devices; and transmitting, via an IoT UID provisioningcircuit, the IoT UIDs for each of the one or more Greenfield devices.

Certain further aspects of the example method are described following,any one or more of which may be present in certain embodiments. Thedevice property data includes at least one of an owner identifier value;a manufacturer identifier value; a Trusted Platform Module (TPM) Key; aMedia Access Control (MAC) address; or a manufacturing serial number.

An example apparatus includes a device registration circuit structuredto interpret a registration request that maps device property data toone or more Greenfield devices; an Internet of Things UniversalIdentifier (IoT UID) generation circuit structured to generate, based atleast in part on the registration request, an IoT UID for each of theone or more Greenfield devices; and an IoT UID provisioning circuitstructured to transmit the IoT UID for each of the one or moreGreenfield devices.

Certain further aspects of the example apparatus are describedfollowing, any one or more of which may be present in certainembodiments. The device property data includes at least one of an owneridentifier value; a manufacturer identifier value; a Trusted PlatformModule (TPM) Key; a Media Access Control (MAC) address; or amanufacturing serial number.

An example method includes identifying one or more Brownfield devices;generating device property data based at least in part on the one ormore Brownfield devices; transmitting, to an Internet of Things (IoT)device registrar server, a registration request that includes the deviceproperty data; and interpreting one or more Internet of Things UniversalIdentifiers (IoT UIDs) generated in response to the transmitting of theregistration request.

Certain further aspects of the example method are described following,any one or more of which may be present in certain embodiments. Theregistration request is for virtual IoT UIDs for the one or moreBrownfield devices. The one or more IoT UIDs are virtual IoT UIDs. Atleast one of identifying the one or more Brownfield devices, generatingthe device property data, or transmitting the registration request areperformed, in part, via a Single Pane of Glass (SPG). The SPG is agraphical user interface. The SPG is hosted by the IoT device registrarserver. The SPG forms part of a device management platform. The SPG isan application programming interface (API). The SPG is hosted by the IoTdevice registrar server. The SPG forms part of a device managementplatform. The method further including verifying that an entityrequesting registration of the one or more Brownfield devices isauthorized to do so. Verifying is based at least in part oncryptographic keys. The cryptographic keys are based at least in part ona public key encryption infrastructure. The device property dataincludes at least one of an owner identifier value; a manufactureridentifier value; a Trusted Platform Module (TPM) Key; a Media AccessControl (MAC) address; or a manufacturing serial number. The methodfurther including interpreting, via a device management platform, amessage from the IoT device registrar server that provides confirmationthat the one or more Brownfield devices were successfully registeredwith an IoT device registry corresponding to the IoT device registrarserver. The method further including interpreting a device event messageand updating a record in an IoT device registry based at least in parton the device event message.

An example apparatus includes a display circuit structured to generate agraphical user interface configured to receive one or more user inputcommand values corresponding to device property data for one or moreBrownfield devices; a requestor circuit structured to generate a virtualregistration request that includes the device property data; a requestprovisioning circuit structured to transmit the virtual registrationrequest to an Internet of Things (IoT) device registrar server; anInternet of Things Universal Identifier (IoT UID) processing circuitstructured to interpret one or more virtual IoT UIDs generated by theIoT device registrar server in response to the virtual registrationrequest; and an IoT UID provisioning circuit structured to at least oneof: transmit the one or more virtual IoT UIDs; or display the one ormore virtual IoT UIDs on an electronic display.

Certain further aspects of the example apparatus are describedfollowing, any one or more of which may be present in certainembodiments. The apparatus further including a verification circuitstructured to verify that an entity requesting registration of the oneor more Brownfield devices is authorized to do so. The device propertydata includes at least one of an owner identifier value; a manufactureridentifier value; a Trusted Platform Module (TPM) Key; a Media AccessControl (MAC) address; or a manufacturing serial number.

An example apparatus includes a device registration request circuitstructured to interpret a virtual registration request that maps deviceproperty data to one or more Brownfield devices; an Internet of ThingsUniversal Identifier (IoT UID) generation circuit structured togenerate, based at least in part on the virtual registration request, anIoT UID for each of the one or more Brownfield devices; a recordmanagement circuit structured to generate a record for each of the IoTUIDs, wherein the record management circuit is further structured toassociate each of the IoT UIDs with portions of the device property datacorresponding to a distinct one of the one or more Brownfield devices;and an IoT UID provisioning circuit structured to transmit each of theIoT UIDs.

Certain further aspects of the example apparatus are describedfollowing, any one or more of which may be present in certainembodiments. The apparatus further including a verification circuitstructured to verify that an entity requesting registration of the oneor more Brownfield devices is authorized to do so. The device propertydata includes at least one of an owner identifier value; a manufactureridentifier value; a Trusted Platform Module (TPM) Key; a Media AccessControl (MAC) address; or a manufacturing serial number.

An example method including interpreting, via a device registrationrequest circuit, a virtual registration request that maps deviceproperty data to one or more Brownfield devices; generating, via anInternet of Things Universal Identifier (IoT UID) generation circuit,based at least in part on the virtual registration request, an IoT UIDfor each of the one or more Brownfield devices; generating, via a recordmanagement circuit, a record for each of the IoT UIDs; associating, viathe record management circuit, each of the IoT UIDs with portions of thedevice property data corresponding to a distinct one of the one or moreBrownfield devices; and transmitting, via an IoT UID provisioningcircuit, each of the IoT UIDs.

Certain further aspects of the example method are described following,any one or more of which may be present in certain embodiments. Themethod further including verifying that an entity requestingregistration of the one or more Brownfield devices is authorized to doso. The device property data includes at least one of an owneridentifier value; a manufacturer identifier value; a Trusted PlatformModule (TPM) Key; a Media Access Control (MAC) address; or amanufacturing serial number.

An example method includes manufacturing at least a portion of aGreenfield device generating, via a device management platform, deviceproperty data corresponding to the Greenfield device; generating, viathe device management platform, a virtual registration request thatincludes the device property data; transmitting, via the devicemanagement platform, the virtual registration request to an IoT deviceregistrar server; and interpreting, via the device management platform,an IoT UID generated by the IoT device registrar server in response tothe device property data.

Certain further aspects of the example method are described following,any one or more of which may be present in certain embodiments. Thegenerating and transmitting the device property data is facilitated by abootstrapping process initiated by the Greenfield device. The methodfurther including verifying that an entity requesting registration ofthe Greenfield device is authorized to do so. The verifyingauthorization of the entity is based at least in part on cryptographickeys. The verifying authorization of the entity is based at least inpart on a Public Key Infrastructure (PKI). The method further includinginterpreting a device event message and updating a record in an IoTdevice registry based at least in part on the device event message.

An example system including one or more manufacturing componentsstructured to manufacture at least a portion of a Greenfield device; anda device management platform structured to: generate device propertydata corresponding to the Greenfield device; generate a virtualregistration request that includes the device property data; transmitthe virtual registration request to an IoT device registrar server; andinterpret an IoT UID generated by the IoT device registrar server inresponse to the virtual registration request.

Certain further aspects of the example system are described following,any one or more of which may be present in certain embodiments. Thedevice management platform comprises a Single Pane of Glass (SPG). Thedevice property data includes an owner identifier value. The deviceproperty data includes a manufacturer identifier value. The deviceproperty data includes a Trusted Platform Module (TPM) Key. The deviceproperty data includes a Media Access Control (MAC) address. The deviceproperty data includes a serial number.

An example apparatus including device property data; and a bootstrappingcircuit structured to: initiate a virtual registration request thatincludes the device property data; and transmit the virtual registrationrequest to an IoT device registrar server.

Certain further aspects of the example apparatus are describedfollowing, any one or more of which may be present in certainembodiments. The device property data includes an owner identifiervalue. The device property data includes at least one of a manufactureridentifier value or a serial number. The device property data includesat least one of a Trusted Platform Module (TPM) Key or a Media AccessControl (MAC) address.

An example method including powering-on a Greenfield device; andinitiating a bootstrapping process on the Greenfield device structuredto virtually register the Greenfield device with an IoT deviceregistrar.

Certain further aspects of the example method are described following,any one or more of which may be present in certain embodiments. Theregistration is pre-sale. The registration is post-sale. The methodfurther including releasing the Greenfield device for use by an enduser. The method further including embedding an IoT UID in theGreenfield device, wherein embedding comprises storing the IoT UID in amemory location of the Greenfield device. The method further includingembedding an IoT UID in the Greenfield device, wherein embeddingcomprises installing a component into the Greenfield device, and whereinthe component includes the IoT UID.

An example method including interpreting, via a device registrationrequest circuit, a virtual registration request that maps deviceproperty data to one or more Greenfield devices; generating, via an IoTUID generation circuit, based at least in part on the virtualregistration request, an IoT UID for each of the one or more Greenfielddevices; generating, via a record management circuit, a record for eachof the IoT UIDs; associating, via the record management circuit, each ofthe IoT UIDs with portions of the device property data corresponding toa distinct one of the one or more Greenfield devices; and transmitting,via an IoT UID provisioning circuit, the IoT UIDs.

Certain further aspects of the example method are described following,any one or more of which may be present in certain embodiments. The IoTUIDs are transmitted to a device management platform operated by amanufacturer of the one or more Greenfield devices. The IoT UIDs aretransmitted to a device management platform operated by an IoT deviceregistrar. The IoT UIDs are transmitted to a device management platformoperated by an end user.

An example apparatus includes a property-monitoring circuit structuredto: generate a query for device property data for an Internet of Things(IoT) device to an IoT device registrar server; interpret the deviceproperty data received from the IoT device registrar server to determinewhether there is a change in the device property data; if theproperty-monitoring circuit determines that there is a change in thedevice property data, generate a notification of the change; andtransmit the notification of the change to the IoT device registrarserver.

Certain further aspects of the example apparatus are describedfollowing, any one or more of which may be present in certainembodiments. The query is initiated by at least one of: the device, auser of the device, a seller of the device, a purchaser of the device, amanufacturer of the device, or the IoT device registrar server. Thechange is determined by analyzing historical device property data. Thechange is determined by monitoring a device property change flag. Thechange comprises a change in device hardware. The change comprises achange in a network. The change comprises a change in ownership of thedevice. The change comprises a security event. The determining that thedevice has reached end-of-life comprises receiving a user inputindicating that the device has reached end-of-life. The determining thatthe device has reached end-of-life comprises receiving a securitynotification indicating a device decommissioning. The determining thatthe device has reached end-of-life comprises receiving a decommissionnotification indicating a device decommissioning. Theproperty-monitoring circuit is further structured to generate aquarantine value indicating that a device should be quarantined. Theproperty-monitoring circuit is further structured to generate adecommission value indicating that a device should be decommissioned.The property-monitoring circuit is further structured to generate asecurity value indicating that a device may be subject to a securityevent. The property-monitoring circuit is further structured to generatean ownership notification indicating that an ownership valuecorresponding to the device has changed. The apparatus further includinga display circuit structured to display the notification of the change.The display circuit comprises a Single Pane of Glass (SPG) displaycircuit included in an SPG system. The SPG system comprises a graphicaluser interface. The graphical user interface is hosted by an IoT deviceregistrar that includes the IoT device registrar server. The SPG systemis included in a device management platform. The SPG system comprises anApplication Programing Interface (API). The API is hosted by the IoTdevice registrar. The API is included in a device management platform.

An example method including generating a query for device property datafor an Internet of Things (IoT) device to an IoT device registrarserver; interpreting the device property data received from the IoTdevice registrar server to determine whether there is a change in thedevice property data; if it is determined that there is a change in thedevice property data, generating a notification of the change; andtransmitting the notification of the change to the IoT device registrarserver.

Certain further aspects of the example method are described following,any one or more of which may be present in certain embodiments. Thequery is initiated by at least one of: the device, a user of the device,a seller of the device, a purchaser of the device, a manufacturer of thedevice, or the IoT device registrar server. The change is determined byanalyzing historical device property data. The change is determined bymonitoring a device property change flag. The change comprises a changein device hardware. The change comprises a change in a network. Thechange comprises a change in ownership of the device. The changecomprises a security event. The determining that the device has reachedend-of-life comprises receiving a user input indicating that the devicehas reached end-of-life. The determining that the device has reachedend-of-life comprises receiving a security notification indicating adevice decommissioning. The determining that the device has reachedend-of-life comprises receiving a decommission notification indicating adevice decommissioning. The method further including generating aquarantine value indicating that a device should be quarantined. Themethod further including generating a decommission value indicating thata device should be decommissioned. The method further includinggenerating a security value indicating that a device may be subject to asecurity event. The method further including generating an ownershipnotification indicating that an ownership value corresponding to thedevice has changed. The method further including displaying thenotification of the change via a display circuit. The notification ofthe change is displayed via a Single Pane of Glass (SPG) system. The SPGsystem comprises a graphical user interface. The graphical userinterface is hosted by an IoT device registrar that includes the IoTdevice registrar server. The SPG system is included in a devicemanagement platform. The SPG system comprises an Application ProgramingInterface (API). The API is hosted by the IoT device registrar. The APIis included in a device management platform.

An example method includes determining that a device has reachedend-of-life; generating a query for Internet of Things UniversalIdentification (IoT UID) data corresponding to the device to an IoTdevice registrar server; interpreting IoT UID data received from the IoTdevice registrar server to identify a set of IoT UIDs corresponding tothe device; identifying a first UID list including a first subset of theset of IoT UIDs to be reused; identifying a second UID list including asecond subset of the set of IoT UIDs, different from the first subset,to be retired; and transmitting the first UID list and the second UIDlist to the IoT device registrar server.

Certain further aspects of the example method are described following,any one or more of which may be present in certain embodiments. Eitherof the first subset or the second subset of the set of IoT UIDs is anempty subset. The method further including storing the second UID list,including the second subset of the set of IoT UIDs to be retired in aglobal retired UID registry, in the IoT device registrar server. Thedetermining that the device has reached end-of-life comprises receivinga user input indicating that the device has reached end-of-life. Thedetermining that the device has reached end-of-life comprises receivinga security notification indicating a device decommissioning. Thedetermining that the device has reached end-of-life comprises receivinga decommission notification indicating a device decommissioning.

An example apparatus includes a device retirement circuit structured todetermine that a device has reached end-of-life; a query-generatingcircuit structured to generate a query for Internet of Things UniversalIdentification (IoT UID) data corresponding to the device to an IoTdevice registrar server; an IoT UID interpretation circuit structuredto: interpret the IoT UID data received from the IoT device registrarserver to identify a set of IoT UIDs corresponding to the device;identify a first UID list including a first subset of the set of IoTUIDs to be reused; and identify a second UID list including a secondsubset of the set of IoT UIDs, different from the first subset, to beretired; and a retirement reporting circuit structured to transmit thefirst UID list and the second UID list to the IoT device registrarserver.

Certain further aspects of the example apparatus are describedfollowing, any one or more of which may be present in certainembodiments. Either of the first subset or the second subset of the setof IoT UIDs is an empty subset. The second UID list, including thesecond subset of the set of IoT UIDs to be retired in a global retiredUID registry, is stored in the IoT device registrar server. Thedetermining that the device has reached end-of-life comprises receivinga user input indicating that the device has reached end-of-life. Thedetermining that the device has reached end-of-life comprises receivinga security notification indicating a device decommissioning. Thedetermining that the device has reached end-of-life comprises receivinga decommission notification indicating a device decommissioning.

An example method includes interpreting, via a user input processingcircuit, a user input identifying a device to be retired; generating aquery for Internet of Things Universal Identification (IoT UID) datacorresponding to the device to an IoT device registrar server;interpreting the IoT UID data received from the IoT device registrarserver to identify a set of IoT UIDs corresponding to the device;identifying a first UID list including a first subset of the set of IoTUIDs to be reused; identifying a second UID list including a secondsubset of the set of IoT UIDs, different from the first subset, to beretired; transmitting the first UID list and the second UID list to theIoT device registrar server; interpreting, via the IoT device registrarserver, the first UID list and the second UID list corresponding to thedevice; and displaying, via a display circuit, the first UID list andthe second UID list corresponding to the device.

Certain further aspects of the example method are described following,any one or more of which may be present in certain embodiments. Eitherof the first subset or the second subset of the set of IoT UIDs is anempty subset. The method further including storing the second UID list,including the second subset of the set of IoT UIDs to be retired in aglobal retired UID registry, in the IoT device registrar server.

An example apparatus includes a user input processing circuit structuredto interpret a user input identifying a device to be retired; aquery-generating circuit structured to generate a query for Internet ofThings Universal Identification (IoT UID) data corresponding to thedevice to an IoT device registrar server; an IoT UID interpretationcircuit structured to: interpret the IoT UID data received from the IoTdevice registrar server to identify a set of IoT UIDs corresponding tothe device; identify a first UID list including a first subset of theset of IoT UIDs to be reused; and identify a second UID list including asecond subset of the set of IoT UIDs, different from the first subset,to be retired; a device end-of-life interpretation circuit at the IoTdevice registrar server structured to interpret the first UID list andthe second UID list corresponding to the device; and a display circuitstructured to display the first UID list and the second UID listcorresponding to the device.

Certain further aspects of the example apparatus are describedfollowing, any one or more of which may be present in certainembodiments. Either of the first subset or the second subset of the setof IoT UIDs is an empty subset. The second UID list, including thesecond subset of the set of IoT UIDs to be retired in a global retiredUID registry, is stored in the IoT device registrar server.

An example method includes interpreting, via an input processingcircuit, a device property data update request for an Internet of Things(IoT) device; determining, via an IoT UID identification circuit, one ormore Internet of Things Universal Identifications (IoT UIDs)corresponding to the IoT device, based at least in part on the deviceproperty data update request; generating, via a device lookup circuit, aquery that includes the one or more IoT UIDs; retrieving, via the devicelookup circuit, first device property data corresponding to the one ormore IoT UIDs; transmitting, via a query provisioning circuit, the queryto an IoT device registrar server; interpreting, via a device propertyprocessing circuit, the device property data generated by the IoT UIDserver in response to the query, the device property data being includedin a device entry in the IoT UID server corresponding to the IoT device;generating, via the query provisioning circuit, a request to the devicefor second device property data; receiving, via the query provisioningcircuit, the second device property data from the device in response tothe request; transmitting, via the query provisioning circuit, theupdated device property data to the IoT device registrar server inresponse to the request to at least one of: replace at least a portionof the first device property data with the second device property datain the device entry in the IoT device registrar server; or add thesecond device property data to the device entry in the IoT deviceregistrar server; interpreting, via the device property processingcircuit, a comparison between the device property data the updateddevice property data; and displaying, via a display circuit, a result ofthe comparison between the device property data the updated deviceproperty data.

An example apparatus includes an input processing circuit structured tointerpret a device property data update request for an Internet ofThings (IoT) device; an Internet of Things Universal Identification (IoTUID) identification circuit structured to determine one or more IoT UIDscorresponding to the IoT device, based at least in part on the deviceproperty data update request; a device lookup circuit structured to:generate a query that includes the one or more IoT UIDs; and retrievefirst device property data corresponding to the one or more IoT UIDs; aquery provisioning circuit structured to transmit the query to an IoTdevice registrar server; a device property processing circuit structuredto interpret the first device property data generated by the IoT UIDserver in response to the query, the first device property data beingincluded in a device entry in the IoT UID server corresponding to theIoT device, wherein the query provisioning circuit is further structuredto: generate a first request to the device for second device propertydata, receive the second device property data from the device inresponse to the first request, and transmit the second device propertydata to the IoT device registrar server in response to a second requestto at least one of: replace at least a portion of the first deviceproperty data with the second device property data in the device entryin the IoT device registrar server, or add the second device propertydata to the device entry in the IoT device registrar server, and whereinthe device property processing circuit is further structured tointerpret a comparison between the first device property data and thesecond device property data; and a display circuit structured to displaya result of the comparison between the first device property data andthe second device property data.

An example apparatus includes an event data processing circuitstructured to interpret an Internet of Things Universal Identification(IoT UID) and corresponding device property data; an event detectioncircuit structured to determine, based at least in part on the deviceproperty data, an event corresponding to a device corresponding to theIoT UID; and a record management circuit structured to update a recordcorresponding to the IoT UID, based at least in part on the event.

Certain further aspects of the example apparatus are describedfollowing, any one or more of which may be present in certainembodiments. The event comprises determining that the device has reachedend-of-life. The determining that the device has reached end-of-lifecomprises receiving a user input indicating that the device has reachedend-of-life. The determining that the device has reached end-of-lifecomprises receiving a security notification indicating a devicedecommissioning. The determining that the device has reached end-of-lifecomprises receiving a decommission notification indicating a devicedecommissioning.

An example apparatus includes an Internet of Things UniversalIdentification (IoT UID) processing circuit structured to interpret anIoT UID corresponding to a device; a record management circuitstructured to identify, based at least in part on the IoT UID, a recordin a database, the record including device ownership data associatedwith the device; an ownership analysis circuit structured to interpret,based at least in part on the record, the device ownership dataassociated with the device; and an ownership provisioning circuitstructured to transmit the device ownership data.

Certain further aspects of the example apparatus are describedfollowing, any one or more of which may be present in certainembodiments. The device ownership data comprises a record of one or moreentities. The record of one or more entities comprises an historicrecord of one or more entities that have owned the device. The deviceownership data comprises a record of historical ownership. The devicecomprises a plurality of modules, each module having correspondingownership data. The apparatus further including an access restrictioncircuit structured to restrict access to information about the devicefrom an owner of the device. The access restriction circuit is furtherstructured to restrict access to information about a first owner of thedevice from a second owner of the device. The apparatus furtherincluding a display circuit structured to display the device ownershipdata for the device. The apparatus further including an ownership dataupdate provisioning circuit structured to provide updated ownership datato replace the device ownership data associated with the device. Theownership data update provisioning circuit is further structured toprovide updated ownership data for one or more modules of the device.The updated ownership data comprises a claim of ownership of the device.Events resulting in the updated ownership data include at least one of:creation of the device, sale of the device, decommissioning of thedevice, transfer of ownership of the device, or licensing of the device.The apparatus further including a security notification provisioningcircuit structured to: compare the device ownership data to a record ofauthorized owners; and generate a security notification if the deviceownership data is not included in the record of authorized owners. Thedatabase comprises a blockchain. The apparatus further including adevice theft notification circuit structured to certify that the deviceis not a stolen device. The apparatus further including a device titlecertification circuit structured to certify that the device has a fullyaccountable chain of title. The apparatus further including a trustindicator provisioning circuit structured to provide a trust indicatorfor the device. The trust indicator comprises a numeric value. The trustindicator comprises an enumerated value. The trust indicator isdisplayed as a color-coded value. A value of the trust indicator isbased at least in part on a location of the device. A value of the trustindicator is based at least in part on a time period. A value of thetrust indicator is based at least in part on at least one of a softwareversion or a firmware version of the device. Determining the trustindicator is based at least in part on artificial intelligence. Thetrust indicator is reflective of the device being a Greenfield device.The trust indicator is reflective of the device being a Brownfielddevice. The trust indicator is reflective of the device being a virtualdevice. The trust indicator is reflective of the device being ameta-device. The trust indicator is displayed as at least one of: atleast one of: numeric based, color based, symbol based, alphanumericbased, letter based. The apparatus further including an asking priceevaluation circuit structured to evaluate an asking price for the devicebased on at least one of: the device ownership data; a certificationthat the device is not a stolen device; or a certification that thedevice has a fully accountable chain of title. The asking priceevaluation circuit is further structured to evaluate an asking price fora group of devices based on ownership data for each device. Theapparatus further including a supply chain validation circuit structuredto validate a supply chain. The validating the supply chain comprisesdetermining whether modules of the device were sourced from authorizedvendors. The validating the supply chain comprises determining whethermodules of the device were sourced from fair trade certified sources.The apparatus further including a carbon rating provisioning circuitstructured to provide a carbon rating of the device based on knownratings of sources of modules of the device, determined based on thedevice ownership data. The apparatus further including a device propertydetection circuit structured to detect a device property that indicatesa change in ownership data. The device property comprises a location ofthe device.

An example method includes interpreting, via an Internet of ThingsUniversal Identification (IoT UID) processing circuit, an IoT UIDcorresponding to a device; identifying, via a record management circuitand based at least in part on the IoT UID, a record in a database, therecord including device ownership data associated with the device;interpreting, via an ownership analysis circuit and based at least inpart on the record, the device ownership data; and transmitting, via anownership provisioning circuit, the device ownership data.

Certain further aspects of the example method are described following,any one or more of which may be present in certain embodiments. Thedevice ownership data comprises a record of one or more entities. Therecord of one or more entities comprises an historic record of one ormore entities that have owned the device. The device ownership datacomprises a record of historical ownership. The device comprises aplurality of modules, each module having corresponding ownership data.The method further including restricting access to information about thedevice from an owner of the device. The method further includingrestricting access to information about a first owner of the device froma second owner of the device. The method further including displayingthe device ownership data for the device. The method further includingproviding updated ownership data to replace the device ownership dataassociated with the device. The method further including providingupdated ownership data for one or more modules of the device. Theupdated ownership data comprises a claim of ownership of the device.Events resulting in the updated ownership data include at least one of:creation of the device, sale of the device, decommissioning of thedevice, transfer of ownership of the device, or licensing of the device.The method further including comparing the device ownership data to arecord of authorized owners; and generating a security notification ifthe device ownership data is not included in the record of authorizedowners. The database comprises a blockchain. The method furtherincluding certifying that the device is not a stolen device. The methodfurther including certifying that the device has a fully accountablechain of title. The method further including providing a trust indicatorfor the device. The trust indicator comprises a numeric value. The trustindicator comprises an enumerated value. The trust indicator isdisplayed as a color-coded value. A value of the trust indicator isbased at least in part on a location of the device. A value of the trustindicator is based at least in part on a time period. A value of thetrust indicator is based at least in part on at least one of a softwareversion or a firmware version of the device. Determining the trustindicator is based at least in part on artificial intelligence. Thetrust indicator is reflective of the device being a Greenfield device.The trust indicator is reflective of the device being a Brownfielddevice. The trust indicator is reflective of the device being aGreenfield device. The trust indicator is reflective of the device beinga Brownfield device. The trust indicator is displayed as at least oneof: numeric based, color based, symbol based, alphanumeric based, orletter based. The method further including evaluating an asking pricefor the device based on at least one of: the device ownership data; acertification that the device is not a stolen device; or a certificationthat the device has a fully accountable chain of title. The methodfurther including evaluating an asking price for a group of devicesbased on ownership data for each device. The method further includingvalidating a supply chain. The validating the supply chain comprisesdetermining whether modules of the device were sourced from authorizedvendors. The validating the supply chain comprises determining whethermodules of the device were sourced from fair trade certified sources.The method further including providing a carbon rating of the devicebased on known ratings of sources of modules of the device, determinedbased on the device ownership data. The method further includingdetecting a device property that indicates a change in ownership data.The device property comprises a location of the device. The methodfurther including interpreting a device event message and updating arecord in an IoT device registry based at least in part on the deviceevent message.

An example system includes a database structured to store recordsassociating Internet of Things Universal Identifications (IoT UIDs) withdevice ownership data; and a server structured to: communicate with thedatabase interpret an IoT UID corresponding to a device; identify, basedat least in part on the IoT UID corresponding to the device, a record inthe database, the record including the device ownership data associatedwith the device; interpret, based at least in part on the record, thedevice ownership data; and transmit the device ownership data.

Certain further aspects of the example system are described following,any one or more of which may be present in certain embodiments. Thedevice ownership data comprises a record of historical ownership. Thedevice comprises a plurality of modules, each module havingcorresponding ownership data. The server is further structured torestrict access to information about the device from an owner of thedevice. The server is further structured to provide updated ownershipdata to replace the device ownership data associated with the device.

An example method includes interpreting, via an input processingcircuit, user input identifying a device ownership query for a device;generating, via a query provisioning circuit, a query for an Internet ofThings Universal Identification (IoT UID), corresponding to the device,to an IoT device registrar server; identifying, via a record managementcircuit and based at least in part on the IoT UID, a record in adatabase at the IoT device registrar server, the record including deviceownership data associated with the device; interpreting, via anownership analysis circuit and based at least in part on the record, thedevice ownership data; and transmitting, via an ownership provisioningcircuit, the device ownership data to a user.

Certain further aspects of the example method are described following,any one or more of which may be present in certain embodiments. Thedevice ownership data comprises a record of historical ownership. Thedevice comprises a plurality of modules, each module havingcorresponding ownership data. The method further including restrictingaccess to information about the device from an owner of the device. Themethod further including providing updated ownership data to replace thedevice ownership data associated with the device.

An example apparatus includes an input processing circuit structured tointerpret user input identifying a device ownership query for a device;a query provisioning circuit structured to generate a query for anInternet of Things Universal Identification (IoT UID) corresponding tothe device to an IoT device registrar server; a record managementcircuit structured to identify, based at least in part on the IoT UID, arecord in a database at the IoT device registrar server, the recordincluding device ownership data associated with the device; an ownershipanalysis circuit structured to interpret, based at least in part on therecord, the device ownership data; and an ownership provisioning circuitstructured to transmit the device ownership data to a user.

Certain further aspects of the example method are described following,any one or more of which may be present in certain embodiments. Thedevice ownership data comprises a record of historical ownership. Thedevice comprises a plurality of modules, each module havingcorresponding ownership data. The apparatus further including an accessrestriction circuit structured to restrict access to information aboutthe device from an owner of the device. The apparatus further includingan ownership data update provisioning circuit structured to provideupdated ownership data to replace the device ownership data associatedwith the device.

An example system includes an input processing circuit structured tointerpret user input identifying a device ownership query for a device;a query provisioning circuit structured to generate a query for anInternet of Things Universal Identification (IoT UID) corresponding tothe device; a database structured to store records associating IoT UIDswith device ownership data; and a server structured to: communicate withthe database; interpret the query corresponding to the device; identifyan IoT UID associated with the device; identify, based at least in parton the IoT UID associated with the device, a record in the database, therecord including the device ownership data associated with the device;interpret, based at least in part on the record, the device ownershipdata; and transmit the device ownership data.

Certain further aspects of the example system are described following,any one or more of which may be present in certain embodiments. Thedevice ownership data comprises a record of historical ownership. Thedevice comprises a plurality of modules, each module havingcorresponding ownership data. The server is further structured torestrict access to information about the device from an owner of thedevice. The server is further structured to provide updated ownershipdata to the database to replace the device ownership data associatedwith the device.

An example method includes interpreting, via an Internet of ThingsUniversal Identifier (IoT UID) processing circuit, an IoT UIDcorresponding to a device; identifying, via a record management circuitand based at least in part on the IoT UID, a record in a databasecorresponding to the device; determining, via a trust analysis circuitand based at least in part on the record, a risk indicator of thedevice; and transmitting, via an indicator provisioning circuit, therisk indicator.

Certain further aspects of the example method are described following,any one or more of which may be present in certain embodiments. The riskindicator is a numeric value. The risk indicator is an enumerated value.The risk indicator is displayed as a color-coded value. The riskindicator is based at least in part on at least one of a location of thedevice, a time period, a software, or firmware version of the device.The risk indicator is based at least in part on artificial intelligence.The risk indicator is reflective of the device being a Greenfield deviceor a Brownfield device. The method further including authorizing aninteraction with the device based at least in part on the riskindicator. The method further including prohibiting an interaction withthe device based at least in part on the risk indicator. The interactionis an exchange of data with the device or is establishing a networkconnection with the device. The method further including adjusting therisk indicator based on an event of the device, wherein the event is atleast one of a transfer of ownership, patching of the device, or anupdating of a software and/or a firmware of the device. The methodfurther including interpreting a device event message and updating arecord in an IoT device registry based at least in part on the deviceevent message.

An example apparatus includes an Internet of Things Universal Identifier(IoT UID) processing circuit structured to interpret an IoT UIDcorresponding to a device; a record management circuit structured toidentify, based at least in part on the IoT UID, a record in a databasecorresponding to the device; a trust analysis circuit structured todetermine, based at least in part on the record, a risk indicator of thedevice; and an indicator provisioning circuit structured to transmit therisk indicator.

Certain further aspects of the example apparatus are describedfollowing, any one or more of which may be present in certainembodiments. The risk indicator is a numeric value. The risk indicatoris an enumerated value. The risk indicator is displayed as a color-codedvalue. The risk indicator is based at least in part on at least one of alocation of the device, a time period, a software, or firmware versionof the device. The risk indicator is based at least in part onartificial intelligence. The risk indicator is reflective of the devicebeing a Greenfield device or a Brownfield device. The apparatus furtherincluding a trust indicator processing circuit structured to authorizean interaction with the device based at least in part on the riskindicator. The apparatus further including a trust indicator processingcircuit structured to prohibit an interaction with the device based atleast in part on the risk indicator. The apparatus wherein theinteraction is an exchange of data with the device or is establishing anetwork connection with the device. The apparatus wherein the trustanalysis circuit is further structured to adjust the risk indicatorbased on an event of the device, wherein the event is at least one of atransfer of ownership, patching of the device, or an updating of asoftware and/or a firmware of the device.

An example method includes interpreting, via an Internet of ThingsUniversal Identifier (IoT UID) processing circuit, an IoT UIDcorresponding to a device; generating, via a trust verification circuit,a trust indicator request value that includes the IoT UID correspondingto the device; transmitting, via a trust indicator request provisioningcircuit, the trust indicator request value to an IoT device registrarserver; and interpreting, via a trust indicator processing circuit, atrust indicator generated by the IoT device registrar server in responseto the trust indicator request value.

Certain further aspects of the example method are described following,any one or more of which may be present in certain embodiments. Thetrust indicator is based at least in part on at least one of a locationof the device, a time period, a software, or firmware version of thedevice. The method further including authorizing an interaction with thedevice based at least in part on the trust indicator. The method furtherincluding prohibiting an interaction with the device based at least inpart on the trust indicator. The trust indicator request furthercomprises contextual data and wherein the trust indicator is based onthe contextual data. The contextual data comprises at least one of alocation, a time, or an operation for execution by the device.

An example apparatus includes an Internet of Things Universal Identifier(IoT UID) processing circuit structured to interpret an IoT UIDcorresponding to a device; a trust verification circuit structured togenerate a trust indicator request value that includes the IoT UIDcorresponding to the device; a trust indicator request provisioningcircuit structured to transmit the trust indicator request value to anIoT device registrar server; and a trust indicator processing circuitstructured to interpret a trust indicator generated by the IoT deviceregistrar server in response to the trust indicator request value.

Certain further aspects of the example apparatus are describedfollowing, any one or more of which may be present in certainembodiments. The trust indicator is based at least in part on at leastone of a location of the device, a time period, a software, or firmwareversion of the device. The trust indicator processing circuit is furtherconfigured to authorize an interaction with the device based at least inpart on the trust indicator. The trust indicator processing circuit isfurther configured to prohibit an interaction with the device based atleast in part on the trust indicator. The trust indicator requestfurther comprises contextual data and wherein the trust indicator isbased on the contextual data. The contextual data comprises at least oneof a location, a time, or an operation for execution by the device.

An example system includes at least one processor; an electronicdisplay; and a memory device storing an application that adapts the atleast one processor to: interpret an Internet of Things UniversalIdentifier (IoT UID) corresponding to a device; transmit the IoT UID;interpret at least one of a risk indicator or a trust indicatortransmitted in response to transmission of the IoT UID by the at leastone processor; and display the at least one of the risk indicator or thetrust indicator on the electronic display.

Certain further aspects of the example system are described following,any one or more of which may be present in certain embodiments. Theapplication further adapts the at least one processor to prohibit aninteraction with the device corresponding to the IoT UID based at leastin part on the at least one of the risk indicator or the trustindicator. The application further adapts the at least one processor toauthorize an interaction with the device corresponding to the IoT UIDbased at least in part on the at least one of the risk indicator or thetrust indicator. The at least one processor transmits the IoT UIDcorresponds to a unique combination of properties of the device. Thedevice is registered with an IoT device registrar.

An example method includes interpreting, via an Internet of Things (IoT)Universal Identification (UID) processing circuit, an IoT UIDcorresponding to a device in a metaverse; identifying, via a recordmanagement circuit and based at least in part on the IoT UID, a recordin a database corresponding to the device in the metaverse; determining,via a trust analysis circuit and based at least in part on the record, atrust indicator of the device in the metaverse; and transmitting, via atrust indicator provisioning circuit, the trust indicator.

Certain further aspects of the example method are described following,any one or more of which may be present in certain embodiments. Thedevice in the metaverse is at least one of a server; a user; an avatar;an area; or an object. The device in the metaverse is at least one of avirtual device; a real-world device; or a meta-device. The device in themetaverse is an area of the metaverse. The area in the metaverse is aroom in the metaverse. The trust indicator is at least one of a numericvalue; or an enumerated value. The trust indicator is displayed as acolor-coded value. The trust indicator comprises one or more of a trustlevel; a trust score; or a trust rating. The trust indicator is based atleast in part on one of a location of the device; a time period; asoftware and/or firmware version of the device; a trust indicator of adevice associated with the device; or a trust indicator of a userassociated with of the device. The trust indicator is based at least inpart on artificial intelligence. The trust indicator is reflective ofthe device being at least one of a Greenfield device; or a Brownfielddevice. The method further including displaying the trust indicator. Themethod further including authorizing an interaction with the devicebased at least in part on the trust indicator. The method furtherincluding prohibiting an interaction with the device based at least inpart on the trust indicator. The interaction is an exchange of data withthe device. The interaction is establishing a network connection withthe device. The method further including adjusting the trust indicatorbased on an event of the device. The event is a transfer of ownership.The event is a patching of the device. The event is an updating at leastone of software or firmware of the device. The method further includinga parental control software agent. The method further includingproviding the trust indicator to a user before the user enters an areaof the metaverse containing the device. Providing the trust indicator toa user before the user enters the area of the metaverse is based atleast in part on a trust indicator of the area of the metaverse. Thearea of the metaverse contains a plurality of devices. The trustindicator of the area in the metaverse is based at least in part on acombination of trust indicators of the plurality of devices in the area.The trust indicator of the device is based at least in part on acombination of trust indicators of a plurality of modules associatedwith the device. The method further including updating the trustindicator based on an interaction with the device. The method furtherincluding interpreting a device event message and updating a record inan IoT device registry based at least in part on the device eventmessage.

An example apparatus includes an Internet of Things (IoT) UniversalIdentification (UID) processing circuit structured to interpret an IoTUID corresponding to a device in a metaverse; a record managementcircuit structured to identify, based at least in part on the IoT UID, arecord in a database corresponding to the device in the metaverse; atrust analysis circuit structured to determine, based at least in parton the record, a trust indicator of the device in the metaverse; and atrust indicator provisioning circuit structured to transmit the trustindicator.

Certain further aspects of the example method are described following,any one or more of which may be present in certain embodiments. Thedevice in the metaverse is at least one of a server; a user; an avatar;an area; or an object. The trust indicator is displayed as a color-codedvalue. The trust indicator comprises one or more of a trust level; atrust score; or a trust rating. The trust indicator is based at least inpart on one of a location of the device; a time period; a softwareand/or firmware version of the device; a trust indicator of a deviceassociated with the device; or a trust indicator of a user associatedwith of the device. The trust indicator is reflective of the devicebeing at least one of a Greenfield device; or Brownfield device. Theapparatus further including displaying the trust indicator. Theapparatus further including prohibiting an interaction with the devicebased at least in part on the trust indicator. The apparatus furtherincluding adjusting the trust indicator based on an event of the device.The apparatus further including providing the trust indicator to a userbefore the user enters an area of the metaverse containing the device.The apparatus of further including updating the trust indicator based onan interaction with the device.

An example method includes interpreting, via an Internet of Things (IoT)Universal Identification (UID) processing circuit, an IoT UIDcorresponding to a device in a metaverse; generating, via a trustverification circuit, a trust indicator request value that includes theIoT UID corresponding to the device in the metaverse; transmitting, viaa trust indicator request provisioning circuit, a trust indicatorrequest to an IoT device registrar server; and interpreting, via a trustindicator processing circuit, a trust indicator generated by the IoTdevice registrar server in response to the trust indicator request.

Certain further aspects of the example method are described following,any one or more of which may be present in certain embodiments. Thedevice in the metaverse is at least one of a server; a user; an avatar;or an object. The trust indicator is displayed as a color-coded value.The trust indicator comprises one or more of a trust level; a trustscore; or a trust rating. The trust indicator is based at least in parton one of a location of the device; a time period; a software and/orfirmware version of the device; a trust indicator of a device associatedwith the device; or a trust indicator of a user associated with of thedevice. The trust indicator is reflective of the device being at leastone of a Greenfield device; or a Brownfield device. The method furtherincluding displaying the trust indicator. The method further includingprohibiting an interaction with the device based at least in part on thetrust indicator. The method further including adjusting the trustindicator based on an event of the device. The method further includingproviding the trust indicator to a user before the user enters an areaof the metaverse containing the device. The method further includingupdating the trust indicator based on an interaction with the device.

An example apparatus includes an Internet of Things (IoT) UniversalIdentification (UID) processing circuit structured to interpret an IoTUID corresponding to a device in a metaverse; a trust verificationcircuit structured to generate a trust indicator request value thatincludes the IoT UID corresponding to the device in the metaverse; atrust indicator request provisioning circuit structured to transmit atrust indicator request to an IoT device registrar server; and a trustindicator processing circuit structured to interpret a trust indicatorgenerated by the IoT device registrar server in response to the trustindicator request.

Certain further aspects of the example apparatus are describedfollowing, any one or more of which may be present in certainembodiments. The device in the metaverse is at least one of a server; auser; an avatar; or an object. The trust indicator is displayed as acolor-coded value. The trust indicator comprises one or more of a trustlevel; a trust score; or a trust rating. The trust indicator is based atleast in part on one of a location of the device; a time period; asoftware and/or firmware version of the device; a trust indicator of adevice associated with the device; or a trust indicator of a userassociated with of the device. The trust indicator is reflective of thedevice being at least one of a Greenfield device; or a Brownfielddevice. The apparatus further including displaying the trust indicator.The apparatus further including prohibiting an interaction with thedevice based at least in part on the trust indicator. The apparatusfurther including adjusting the trust indicator based on an event of thedevice. The apparatus further including providing the trust indicator toa user before the user enters an area of the metaverse containing thedevice. The apparatus further including updating the trust indicatorbased on an interaction with the device.

An example method includes interpreting, via an Internet of Things (IoT)Universal Identification (UID) processing circuit, an IoT UIDcorresponding to a device in an augmented reality (AR); identifying, viaa record management circuit and based at least in part on the IoT UID, arecord in a database corresponding to the device in the AR; determining,via a trust analysis circuit and based at least in part on the record, atrust indicator of the device in the AR; and transmitting, via a trustindicator provisioning circuit, the trust indicator.

Certain further aspects of the example method are described following,any one or more of which may be present in certain embodiments. Thedevice in the AR is at least one of an IoT device; a server; a user; oran avatar. The device in the AR corresponds to an area of a metaverse.The area in the metaverse is a room in the metaverse. The device in theAR is an object. The object is at least one of a virtual device; areal-world device; or a meta-device. The device in the AR is areal-world device. The trust indicator is at least one of a numericvalue; or an enumerated value. The trust indicator comprises one or moreof a trust level; a trust score; or a trust rating. The method, furtherincluding displaying the trust indicator in association with areal-world device. The method further including displaying the trustindicator overlaid on a real-world device. The trust indicator isdisplayed via an AR device. The AR device is one or more of an ARheadset; AR contact lenses; AR glasses, or AR goggles. The trustindicator is displayed as a color-coded value. The trust indicator isbased at least in part on one of a location of the device; a timeperiod; a software and/or firmware version of the device; a trustindicator of a device associated with the device; or a trust indicatorof a user associated with of the device. Determining the trust indicatoris based at least in part on artificial intelligence. The trustindicator is reflective of the device being at least one of a Greenfielddevice; or a Brownfield device. The method further including displayingthe trust indicator. The method further including authorizing aninteraction with the device based at least in part on the trustindicator. The method further including prohibiting an interaction withthe device based at least in part on the trust indicator. Theinteraction is an exchange of data with a device. The interaction is anexchange of data with a device. The interaction is establishing anetwork connection with the device. The method further includingadjusting the trust indicator based on an event of the device. The eventis a transfer of ownership. The event is a patching of the device. Theevent is an updating at least one of software or firmware of the device.The method further including a parental control software agent. Themethod further including providing the trust indicator to a userinteracts with the device. A trust indicator of a device in the AR isbased at least in part on a combination of trust indicators of aplurality of entities in the AR. The method further including providingthe trust indicator of the device to a user before the user enters anarea of a metaverse containing the device. A trust indicator of thedevice is based at least in part on a combination of trust indicators ofa plurality of modules associated with the device. The method furtherincluding updating the trust indicator based on an interaction with thedevice. The method further including interpreting a device event messageand updating a record in an IoT device registry based at least in parton the device event message.

An example apparatus includes an Internet of Things (IoT) UniversalIdentification (UID) processing circuit structured to interpret an IoTUID corresponding to a device in an augmented reality (AR); a recordmanagement circuit structured to identify, based at least in part on theIoT UID, a record in a database corresponding to the device in the AR; atrust analysis circuit structured to determine, based at least in parton the record, a trust indicator of the device in the AR; and a trustindicator provisioning circuit structured to transmit the trustindicator.

Certain further aspects of the example apparatus are describedfollowing, any one or more of which may be present in certainembodiments. The device in the AR is at least one of an IoT device; aserver; a user; or an avatar. The device in the AR corresponds to anarea of a metaverse. The apparatus further including displaying thetrust indicator in association with a real-world device or overlaid onthe real-world device. The trust indicator is displayed via an ARdevice, wherein the AR device is one or more of an AR headset; ARcontact lenses; AR glasses, or AR goggles. The trust indicator isdisplayed as a color-coded value. The trust indicator is based at leastin part on one of a location of the device; a time period; a softwareand/or firmware version of the device; a trust indicator of a deviceassociated with the device; or a trust indicator of a user associatedwith of the device. The apparatus further including authorizing aninteraction with the device based at least in part on the trustindicator. The apparatus further including prohibiting an interactionwith the device based at least in part on the trust indicator. Theapparatus further including adjusting the trust indicator based on anevent of the device. The apparatus further including a parental controlsoftware agent. A trust indicator of a device in the AR is based atleast in part on a combination of trust indicators of a plurality ofdevices in the AR. The apparatus further including providing the trustindicator of the device to a user before the user enters an area of ametaverse containing the device.

An example method includes interpreting, via an Internet of Things (IoT)Universal Identification (UID) processing circuit, an IoT UIDcorresponding to a device in an augmented reality (AR); generating, viaa trust verification circuit, a trust indicator request value thatincludes the IoT UID corresponding to the device in the AR;transmitting, via a trust indicator request provisioning circuit, atrust indicator request to an IoT device registrar server; andinterpreting, via a trust indicator processing circuit, a trustindicator generated by the IoT device registrar server in response tothe trust indicator request.

Certain further aspects of the example method are described following,any one or more of which may be present in certain embodiments. Thedevice in the AR is at least one of an IoT device; a server; a user; oran avatar. The device in the AR corresponds to an area of a metaverse.The method further including displaying the trust indicator inassociation with a real-world device or overlaid on the real-worlddevice. The trust indicator is displayed via an AR device, wherein theAR device is one or more of an AR headset; AR contact lenses; ARglasses, or AR goggles. The trust indicator is displayed as acolor-coded value. The trust indicator is based at least in part on oneof a location of the device; a time period; a software and/or firmwareversion of the device; a trust indicator of a device associated with thedevice; or a trust indicator of a user associated with of the device.The method further including authorizing an interaction with the devicebased at least in part on the trust indicator. The method furtherincluding prohibiting an interaction with the device based at least inpart on the trust indicator. The method further including adjusting thetrust indicator based on an event of the device. The method furtherincluding a parental control software agent. The method wherein a trustindicator of a device in the AR is based at least in part on acombination of trust indicators of a plurality of devices in the AR. Themethod further including providing the trust indicator of the device toa user before the user enters an area of a metaverse containing thedevice.

An example apparatus includes an Internet of Things (IoT) UniversalIdentification (UID) processing circuit structured to interpret an IoTUID corresponding to a device in an augmented reality (AR); a trustverification circuit structured to generate a trust indicator requestvalue that includes the IoT UID corresponding to the device in the AR; atrust indicator request provisioning circuit structured to transmit atrust indicator request to an IoT device registrar server; and a trustindicator processing circuit structured to interpret a trust indicatorgenerated by the IoT device registrar server in response to the trustindicator request.

Certain further aspects of the example apparatus are describedfollowing, any one or more of which may be present in certainembodiments. The device in the AR is at least one of an IoT device; aserver; a user; or an avatar. The device in the AR corresponds to anarea of a metaverse. The apparatus further including displaying thetrust indicator in association with a real-world device or overlaid onthe real-world device. The trust indicator is displayed via an ARdevice, wherein the AR device is one or more of an AR headset; ARcontact lenses; AR glasses, or AR goggles. The trust indicator isdisplayed as a color-coded value. The trust indicator is based at leastin part on one of a location of the device; a time period; a softwareand/or firmware version of the device; a trust indicator of a deviceassociated with the device; or a trust indicator of a user associatedwith of the device. The apparatus further including authorizing aninteraction with the device based at least in part on the trustindicator. The apparatus further including prohibiting an interactionwith the device based at least in part on the trust indicator. Theapparatus further including adjusting the trust indicator based on anevent of the device. The apparatus further including a parental controlsoftware agent. The apparatus wherein a trust indicator of a device inthe AR is based at least in part on a combination of trust indicators ofa plurality of entities in the AR. The apparatus further includingproviding the trust indicator of the device to a user before the userenters an area of a metaverse containing the device.

An example method includes monitoring, via at least one processor, oneor more records in an internet of things (IoT) device registry forchanges in device property data corresponding to one or more devices,each corresponding to one of the one or more records; detecting, via theat least one processor, a change in the device property data of at leastone record; determining, via the at least one processor, that the changecorresponds to a security vulnerability; generating, via at least oneprocessor and responsive to the determined security vulnerability, amessage that identifies a device corresponding to the change in thedevice property data; and transmitting, via the at least one processor,the message.

Certain further aspects of the example method are described following,any one or more of which may be present in certain embodiments. Themethod further including displaying the message. The method furtherincluding logging the change in a database. The method further includingreceiving the message at a device management platform and at least oneof quarantining or patching the device. The message is an alert. Themethod further including adjusting a trust indicator based at least inpart on the change. The trust indicator is at least one of a trustscore, a rating, or a level value. The adjusting is an increase when thechange corresponds to a patching or an updating of software and/orfirmware of the device. The adjusting is a decrease when the changecorresponds to a vulnerability. The change corresponds to an addition ofa new module into the device. The new module is an input/output device.The input/output device is a network interface device. The input/outputdevice is a media device. The change corresponds to a change inownership of the device. The change is a location of the device. Thesecurity vulnerability is based on a software and/or firmware of thedevice. The security vulnerability is based on a hardware version of thedevice. The method further including accessing a securityvulnerabilities database to pull security vulnerability signatures todetermine if a registered device is affected. The method furtherincluding interpreting a device event message and updating a record inan IoT device registry based at least in part on the device eventmessage.

An example method includes at a first time, interpreting, via a deviceproperty data processing circuit, device property data corresponding toa device registered with an IoT device registry; at a second time,interpreting, via the device property data processing circuit, thedevice property data corresponding to the device registered with the IoTdevice registry; detecting, via a change detection circuit, a change inthe device property data between the first time and the second time;generating, via an alert circuit and responsive to detecting the change,a message that identifies the device corresponding to the deviceproperty data; and transmitting, via an alert provisioning circuit, themessage.

Certain further aspects of the example method are described following,any one or more of which may be present in certain embodiments. Themethod further including displaying the message. The method furtherincluding receiving the message at a device management platform and atleast one of quarantining or patching the device. The method furtherincluding adjusting a trust indicator based at least in part on thechange. The method wherein the change corresponds to an addition of anew module into the device. The method wherein the change corresponds toa change in ownership of the device. The method wherein the change is alocation of the device.

An example apparatus includes a device property data processing circuitstructured to: at a first time, interpret, device property datacorresponding to a device registered with an IoT device registry; and ata second time, interpret, the device property data corresponding to thedevice registered with the IoT device registry; a change detectioncircuit structured to detect a change in the device property databetween the first time and the second time; an alert circuit structuredto generate, responsive to the detected change, a message thatidentifies the device corresponding to the device property data; and analert provisioning circuit structured to transmit the message.

Certain further aspects of the example apparatus are describedfollowing, any one or more of which may be present in certainembodiments. The apparatus further including the device property dataprocessing circuit structured to display the message. The apparatusfurther including the device property data processing circuit structuredto receive the message at a device management platform and at least oneof quarantining or patching the device. The apparatus further includingthe device property data processing circuit structured to adjust a trustindicator based at least in part on the change. The change correspondsto an addition of a new module into the device. The change correspondsto a change in ownership of the device. The change is a location of thedevice.

An example system includes a device management platform structured tomanage one or more devices registered with an IoT device registry; and asentry device structured to: monitor the IoT device registry for changesin property data corresponding to the registered one or more devices;detect a change in the property data for at least one of the one or moredevices; determine that the detected change corresponds to a securityvulnerability; generate, responsive to the determined securityvulnerability, a message that identifies the at least one device of theone or more devices; and transmit the message to the device managementplatform, wherein the device management platform is further structuredto: interpret the message transmitted by the sentry device; and at leastone of: quarantine the at least one device; or patch the at least onedevice.

Certain further aspects of the example system are described following,any one or more of which may be present in certain embodiments. Thesystem further including the sentry device structured to display themessage. The system further including the sentry device structured toreceive the message at a device management platform and at least one ofquarantining or patching the one or more devices. The system furtherincluding the sentry device structured to adjust a trust indicator basedat least in part on the change. The change corresponds to an addition ofa new module into the one or more devices. The change corresponds to achange in ownership of the one or more devices. The change is a locationof the one or more devices.

An example method includes interpreting, via a device property dataprocessing circuit, device property data corresponding to a deviceregistered with an IoT device registry; detecting, via a securityanalysis circuit, based at least in part on the device property data,that the device is subject to a security vulnerability; generating,responsive to the detected security vulnerability, via an alert circuit,a message that identifies the device; and transmitting, via an alertprovisioning circuit, the message.

Certain further aspects of the example method are described following,any one or more of which may be present in certain embodiments. Themethod further including displaying the message. The method furtherincluding receiving the message at a device management platform and atleast one of quarantining or patching the device.

An example apparatus includes a device property data processing circuitstructured to interpret device property data corresponding to a deviceregistered with an IoT device registry; a security analysis circuitstructured to determine, based at least in part on the device propertydata, that the device is subject to a security vulnerability; an alertcircuit structured to generate, responsive to the determined securityvulnerability, a message that identifies the device; and an alertprovisioning circuit structured to transmit the message.

Certain further aspects of the example apparatus are describedfollowing, any one or more of which may be present in certainembodiments. The device property data processing circuit furtherstructured to display the message. The device property data processingcircuit further structured to receive the message at a device managementplatform and at least one of quarantining or patching the device.

An example apparatus includes a device property data processing circuitstructured to interpret device property data corresponding to one ormore devices registered with an Internet of Things (IoT) deviceregistry; an outage detection circuit structured to detect an outagepattern in the device property data, the outage pattern corresponding toan outage of the one or more devices; an alert circuit structured to,responsive to the outage pattern, generate an alert message thatidentifies the one or more devices; and an alert provisioning circuitstructured to transmit the alert message.

Certain further aspects of the example apparatus are describedfollowing, any one or more of which may be present in certainembodiments. The outage detection circuit comprises an artificialintelligence circuit structured to detect the outage pattern, based atleast in part on analyzing the device property data using an artificialintelligence process. The artificial intelligence process includes aneural network. The neural network is trained on detecting correlationsbetween outage patterns and at least one of a weather event; acyber-attack; a device failure event; device ownership; a devicemanufacturer; a location; or a network outage. The artificialintelligence process is based at least in part on a deep learningnetwork. The apparatus further including a visualization circuitstructured to generate and transmit outage visualization data configuredto depict a visualization of the outage on an electronic display. Thevisualization is a map. The visualization is a chart depicting an amountof the one or more devices affected by the outage. The alertprovisioning circuit is structured to transmit the alert message to atleast one of a device management platform corresponding to the one ormore devices; a user of the one or more devices; a manufacturer of theone or more devices; or an entity that monitors the one or more devices.The outage detection circuit forms part of a device management platform.The outage detection circuit forms part of the IoT device registry.

An example method includes interpreting, via a device property dataprocessing circuit, device property data corresponding to one or moredevices registered with an Internet of Things (IoT) device registry;detecting, via an outage detection circuit, an outage pattern in thedevice property data, the outage pattern corresponding to an outage ofthe one or more devices; responsive to the outage pattern, generating,via an alert circuit, an alert message that identifies the one or moredevices; and transmitting, via an alert provisioning circuit, the alertmessage.

Certain further aspects of the example method are described following,any one or more of which may be present in certain embodiments. Thedetecting, via the outage detection circuit, an outage pattern in thedevice property data, the outage pattern corresponding to an outage ofthe one or more devices comprises detecting the outage pattern viaanalyzing the device property data with an artificial intelligencecircuit that uses an artificial intelligence process. The artificialintelligence process includes a neural network. The neural network istrained on detecting correlations between outage patterns and at leastone of a weather event; a cyber-attack; a device failure event; deviceownership; a device manufacturer; a location; or a network outage. Themethod further including generating, via a visualization circuit,visualization data configured to depict a visualization of the outage onan electronic display; and transmitting, via the visualization circuit,the visualization data. The visualization is a map. The visualization isa chart depicting an amount of the one or more devices affected by theoutage. The method further including interpreting the visualizationdata; and displaying, via the electronic display, the visualization ofthe outage. The method further including interpreting a device eventmessage and updating a record in an IoT device registry based at leastin part on the device event message.

An example non-transitory computer-readable medium includes instructionsto interpret device property data corresponding to one or more devicesregistered with an Internet of Things (IoT) device registry; detect anoutage pattern in the device property data, the outage patterncorresponding to an outage of the one or more devices; responsive to theoutage pattern, generate an alert message that identifies the one ormore devices; and transmit the alert message.

Certain further aspects of the example non-transitory computer-readablemedium are described following, any one or more of which may be presentin certain embodiments. The stored instructions further adapt the atleast one processor to detect the outage pattern via an artificialintelligence process. The outage pattern is detected based at least inpart on one of a weather event; a cyber-attack; a device failure event;device ownership; a device manufacturer; a location; or a networkoutage.

An example method includes collecting a data set including: one or moreoutage patterns; and device property data; creating a first training setincluding one or more portions of the device property data thatcorrespond to the one or more outage patterns; creating a secondtraining set including one or more portions of the device property datathat incorrectly identify the one or more outage patterns; training theAI on the first training set; and training the AI on the second trainingset.

Certain further aspects of the example method are described following,any one or more of which may be present in certain embodiments. At leastone of the first training set and the second training set is based atleast in part on at least one of a weather event; a cyber-attack; adevice failure event; device ownership; a device manufacturer; alocation; or a network outage.

An example apparatus includes a device property data processing circuitstructured to interpret device property data corresponding to a deviceregistered with an Internet of Things (IoT) device registry; a securityanalysis circuit structured to determine, based at least in part on thedevice property data, that the device is subject to a fraud event; analert circuit structured to generate, responsive to the determined fraudevent, a message that identifies the device; and an alert provisioningcircuit structured to transmit the message.

Certain further aspects of the example apparatus are describedfollowing, any one or more of which may be present in certainembodiments. The security analysis circuit comprises an artificialintelligence circuit structured to detect the fraud event, based atleast in part on analyzing the device property data using an artificialintelligence process. The artificial intelligence process includes aneural network. The neural network is trained on detecting correlationsbetween the fraud event and at least one of a cyber-attack; a softwareversion; a firmware version; a hardware version; an unauthorized access;a device failure event; device ownership; a device manufacturer; alocation; or a network outage. The artificial intelligence process isbased at least in part on a deep learning network. The apparatus furtherincluding a visualization circuit structured to generate and transmitfraud event visualization data configured to depict a visualization ofthe fraud event on an electronic display. The visualization is a map.The visualization is a chart depicting at least one of the deviceaffected by the fraud event. The alert provisioning circuit is furtherstructured to transmit the message to at least one of a devicemanagement platform corresponding to the device; a user of the device; amanufacturer of the device; or an entity that monitors the device. Thesecurity analysis circuit forms part of a device management platform.The security analysis circuit forms part of the IoT device registry. Theapparatus further including a display circuit structured to display themessage. The apparatus further including a fraud event log circuitstructured to log the fraud event in a database. The apparatus furtherincluding a device management platform structured to interpret themessage transmitted by the alert provisioning circuit; and at least oneof quarantine the at least one device; disable the at least one device;disable at least part of the device; disable at least some functionalityof the device; send an alert to the device; send an alert to an entityassociated with the device; or patch the at least one device. Theapparatus further including a trust indicator provisioning circuitstructured to provide a trust indicator for the device, based at leastin part on the determined fraud event. The trust indicator comprises atleast one of: a numeric value, an alphabetic value, or an alphanumericvalue. The trust indicator comprises an enumerated value. The trustindicator is displayed as a color-coded value. A value of the trustindicator is based at least in part on a location of the device. A valueof the trust indicator is based at least in part on a time period. Avalue of the trust indicator is based at least in part on at least oneof a software version or a firmware version of the device. Determiningthe trust indicator is based at least in part on artificialintelligence. The trust indicator is reflective of the device being aGreenfield device. The trust indicator is reflective of the device beinga Brownfield device. The trust indicator is reflective of the devicebeing a virtual device. The trust indicator is reflective of the devicebeing a meta-device. The trust indicator is displayed as at least oneof: numeric based, color based, symbol based, alphanumeric based, orletter based. The trust indicator provisioning circuit is furtherstructured to adjust a value of the trust indicator is adjusted based atleast in part on the determined fraud event. The adjustment is anincrease when the determined fraud event corresponds to at least one ofa patching or an updating of at least one of software or firmware of thedevice. The adjustment is a decrease when the determined fraud eventcorresponds to a cyber-attack. The determined fraud event corresponds toan addition of a new module into the device. The new module is at leastone of an input device or an output device. The at least one of theinput device or the output device is a network interface device. The atleast one of the input device or the output device is a media device.The determined fraud event corresponds to a change in ownership of thedevice. The determined fraud event is based on detecting a change in alocation of the device. The determined fraud event is based on detectinga change in at least one of a software version or a firmware version ofthe device. The determined fraud event is based on detecting a change ina hardware version of the device. The security analysis circuit isfurther structured to access a fraud event database to interpret fraudevent signatures to determine that the device is subject to the fraudevent. The apparatus further including an IoT Universal Identification(UID) processing circuit structured to interpret an IoT UID and thedevice property data; a record management circuit structured toassociate the IoT UID with the device property data via a record; and arecord provisioning circuit structured to transmit the record.

An example method includes interpreting, via a device property dataprocessing circuit, device property data corresponding to a deviceregistered with an Internet of Things (IoT) device registry;determining, via a security analysis circuit based at least in part onthe device property data, that the device is subject to a fraud event;generating, responsive to the determined fraud event, via an alertcircuit, a message that identifies the device; and transmitting, via analert provisioning circuit, the message.

Certain further aspects of the example method are described following,any one or more of which may be present in certain embodiments. Thedetermining, via the security analysis circuit, that the device issubject to a fraud event comprises detecting the fraud event viaanalyzing the device property data with an artificial intelligencecircuit that uses an artificial intelligence process. The artificialintelligence process includes a neural network. The method furtherincluding training the neural network on detecting correlations betweenthe fraud event and at least one of a cyber-attack; a software version;a firmware version; a hardware version; an unauthorized access; a devicefailure event; device ownership; a device manufacturer; a location; or anetwork outage. The artificial intelligence process is based at least inpart on a deep learning network. The method further including generatingand transmitting, via a visualization circuit, fraud event visualizationdata configured to depict a visualization of the fraud event on anelectronic display. The visualization is a map. The visualization is achart depicting at least one of the device affected by the fraud event.The method further including transmitting, via the alert provisioningcircuit, the message to at least one of a device management platformcorresponding to the device; a user of the device; a manufacturer of thedevice; or an entity that monitors the device. The security analysiscircuit forms part of a device management platform. The securityanalysis circuit forms part of the IoT device registry. The methodfurther including displaying the message via a display circuit. Themethod further including logging the fraud event in a database via afraud event log circuit. The method further including interpreting, viaa device management platform, the message transmitted by the alertprovisioning circuit; and by the device management platform, at leastone of: quarantining the device; disabling the device; or patching thedevice. The method further including providing a trust indicator for thedevice, based at least in part on the determined fraud event. The trustindicator comprises at least one of: a numeric value, an alphabeticvalue, or an alphanumeric value. The trust indicator comprises anenumerated value. The trust indicator is displayed as a color-codedvalue. A value of the trust indicator is based at least in part on alocation of the device. A value of the trust indicator is based at leastin part on a time period. A value of the trust indicator is based atleast in part on at least one of a software version or a firmwareversion of the device. Determining the trust indicator is based at leastin part on artificial intelligence. The trust indicator is reflective ofthe device being a Greenfield device. The trust indicator is reflectiveof the device being a Brownfield device. The trust indicator isreflective of the device being a virtual device. The trust indicator isreflective of the device being a meta-device. The trust indicator isdisplayed as at least one of: numeric based, color based, symbol based,alphanumeric based, or letter based. The method further includingadjusting a value of the trust indicator based at least in part on thedetermined fraud event. The adjusting is an increase when the determinedfraud event corresponds to at least one of a patching or an updating ofat least one of software or firmware of the device. The adjusting is adecrease when the determined fraud event corresponds to a cyber-attack.The determined fraud event corresponds to an addition of a new moduleinto the device. The new module is at least one of an input device or anoutput device. The at least one of the input device or the output deviceis a network interface device. The at least one of the input device orthe output device is a media device. The determined fraud eventcorresponds to a change in ownership of the device. The determined fraudevent is based on detecting a change in a location of the device. Thedetermined fraud event is based on detecting a change in at least one ofa software version or a firmware version of the device. The determinedfraud event is based on detecting a change in a hardware version of thedevice. The method further including accessing, by the security analysiscircuit, a fraud event database to interpret fraud event signatures todetermine that the device is subject to the fraud event. The methodfurther including interpreting, via an IoT UID processing circuit, anIoT UID and the device property data; associating, via a recordmanagement circuit, the IoT UID with the device property data via arecord; and transmitting, via a record provisioning circuit, the record.The method further including interpreting a device event message andupdating a record in an IoT device registry based at least in part onthe device event message.

An example apparatus includes a device property data processing circuitstructured to: at a first time, interpret device property datacorresponding to a device registered with an Internet of Things (IoT)device registry; and at a second time, interpret the device propertydata corresponding to the device registered with the IoT deviceregistry; a change detection circuit structured to detect a change inthe device property data between the first time and the second time; afraud detection circuit structured to determine that the changecorresponds to a fraud event; an alert circuit structured to generate,responsive to the determining that the change corresponds to a fraudevent, a message that identifies the device corresponding to the deviceproperty data; and an alert provisioning circuit structured to transmitthe message.

Certain further aspects of the example apparatus are describedfollowing, any one or more of which may be present in certainembodiments. The fraud detection circuit comprises an artificialintelligence circuit structured to detect the fraud event, based atleast in part on analyzing the device property data using an artificialintelligence process. The artificial intelligence process includes aneural network. The neural network is trained on detecting correlationsbetween the fraud event and at least one of a cyber-attack; a softwareversion; a firmware version; a hardware version; an unauthorized access;a device failure event; device ownership; a device manufacturer; alocation; or a network outage.

An example method includes at a first time, interpreting, via a deviceproperty data processing circuit, device property data corresponding toa device registered with an Internet of Things (IoT) device registry; ata second time, interpreting, via the device property data processingcircuit, the device property data corresponding to the device registeredwith the IoT device registry; detecting, via a change detection circuit,a change in the device property data between the first time and thesecond time; determining, by a fraud detection circuit, that the changecorresponds to a fraud event; generating, via an alert circuit andresponsive to the determining that the change corresponds to a fraudevent, a message that identifies the device corresponding to the deviceproperty data; and transmitting, via an alert provisioning circuit, themessage.

Certain further aspects of the example method are described following,any one or more of which may be present in certain embodiments. Thedetermining, via the fraud detection circuit, that the changecorresponds to a fraud event comprises detecting the fraud event viaanalyzing the device property data with an artificial intelligencecircuit that uses an artificial intelligence process. The artificialintelligence process includes a neural network. The neural network istrained on detecting correlations between the fraud event and at leastone of a cyber-attack; a software version; a firmware version; ahardware version; an unauthorized access; a device failure event; deviceownership; a device manufacturer; a location; or a network outage.

An example system includes a device management platform structured tomanage one or more devices registered with an Internet of Things (IoT)device registry; and a fraud detection device structured to: monitor theIoT device registry for changes in device property data corresponding tothe registered one or more devices; detect a change in the deviceproperty data for at least one device among the one or more devices;determine that the detected change corresponds to a fraud event;generate, responsive to the determined fraud event, a message thatidentifies the at least one device; and transmit the message to thedevice management platform, wherein the device management platform isfurther structured to: interpret the message transmitted by the frauddetection device, and at least one of: quarantine the at least onedevice, disable the at least one device, disable at least part of thedevice, disable at least some functionality of the device, send an alertto the device, send an alert to an entity associated with the device, orpatch the at least one device.

Certain further aspects of the example system are described following,any one or more of which may be present in certain embodiments. Thefraud detection device comprises an artificial intelligence circuitstructured to detect the fraud event, based at least in part onanalyzing the device property data using an artificial intelligenceprocess. The artificial intelligence process includes a neural network.The neural network is trained on detecting correlations between thefraud event and at least one of a cyber-attack; a software version; afirmware version; a hardware version; an unauthorized access; a devicefailure event; device ownership; a device manufacturer; a location; or anetwork outage.

An example method includes monitoring, via at least one processor, oneor more records in an Internet of Things (IoT) device registry forchanges in device property data corresponding to one or more devices,each of the one or more devices corresponding to one of the one or morerecords; detecting, via the at least one processor, a change in thedevice property data of at least one record among the one or morerecords; determining, via the at least one processor, that the changecorresponds to a fraud event; generating, via the at least one processorand responsive to the detected fraud event, a message that identifiesthe device, corresponding to the changed device property data; andtransmitting, via the at least one processor, the message.

Certain further aspects of the example method are described following,any one or more of which may be present in certain embodiments. Thedetermining that the change corresponds to a fraud event comprisesdetecting the fraud event via analyzing the device property data with anartificial intelligence circuit that uses an artificial intelligenceprocess. The artificial intelligence process includes a neural network.The neural network is trained on detecting correlations between thefraud event and at least one of a cyber-attack; a software version; afirmware version; a hardware version; an unauthorized access; a devicefailure event; device ownership; a device manufacturer; a location; or anetwork outage.

An example method includes interpreting, via an Internet of ThingsUniversal Identification (IoT UID) processing circuit, an IoT UID anddevice property data corresponding to a meta-device; associating, via arecord management circuit, the IoT UID with the device property data ina record in a database; and transmitting, via a record provisioningcircuit, the record.

Certain further aspects of the example method are described following,any one or more of which may be present in certain embodiments. Themethod further including transmitting at least one of the IoT UID or therecord to a user in a virtual environment. The method further includingdisplaying at least one of the IoT UID or the record in a virtualenvironment. The method further including generating at least one of atrust indicator and/or a risk indicator for the meta-device; and storingthe trust indicator and/or the risk indicator in the record associatedwith the IoT UID. The method further including transmitting the trustindicator and/or the risk indicator to a user in a virtual environment.The method further including displaying the trust indicator and/or therisk indicator in a virtual environment in relation to the meta-device.The method further including interpreting a device event message andupdating a record in an IoT device registry based at least in part onthe device event message.

An example apparatus includes an IoT UID processing circuit structuredto interpret an IoT UID and device property data corresponding to ameta-device a record management circuit structured to associate the IoTUID with the device property data via a record; and a recordprovisioning circuit structured to transmit the record.

Certain further aspects of the example apparatus are describedfollowing, any one or more of which may be present in certainembodiments. The apparatus further including an authentication circuitstructured to generate a trust indicator and/or a risk indicator for themeta-device; and store the trust indicator and/or the risk indicator inthe record associated with the IoT UID. The meta-device lacks areal-world counterpart. The meta-device has at least one real-worldcounterpart. The meta-device has at least two real-world counterparts.The at least two real-world counterparts are in different locations. Thedevice property data is at least one of an NFT, an owner identifiervalue, a manufacturer identifier value, a Trusted Platform Module (TPM)Key, a Media Access Control (MAC) address, a serial number, a softwareversion, or a firmware version. The meta-device is at least one of aGreenfield device or a Brownfield device.

An example apparatus includes an IoT UID processing circuit structuredto interpret an IoT UID associated with a meta-device; a device lookupcircuit structured to generate a query that includes the IoT UID and isstructured to retrieve device property data corresponding to the IoTUID; and a query provisioning circuit structured to transmit the queryto an IoT device registrar server.

Certain further aspects of the example apparatus are describedfollowing, any one or more of which may be present in certainembodiments. The meta-device lacks a real-world counterpart. Themeta-device has at least one real-world counterpart. The meta-device hasat least two real-world counterparts. The at least two real-worldcounterparts are in different locations. The device property data is atleast one of an NFT, an owner identifier value, a manufactureridentifier value, a Trusted Platform Module (TPM) Key, a Media AccessControl (MAC) address, a serial number, a software version, or afirmware version.

The methods and systems described herein may be deployed in part or inwhole through a machine having a computer, computing device, processor,circuit, and/or server that executes computer readable instructions,program codes, instructions, and/or includes hardware configured tofunctionally execute one or more operations of the methods and systemsherein. The terms computer, computing device, processor, circuit, and/orserver, (“computing device”) as utilized herein, should be understoodbroadly. Non-limiting examples include the IoT device registrar server1126 (FIG. 1), the database 1128 (FIG. 1), apparatuses that may formpart of the IoT device registrar server 1126, database, and/or any othercomputing devices, as disclosed herein.

An example computing device includes a computer of any type, capable toaccess instructions stored in communication thereto such as upon anon-transient computer readable medium, whereupon the computer performsoperations of the computing device upon executing the instructions. Incertain embodiments, such instructions themselves comprise a computingdevice. Additionally or alternatively, a computing device may be aseparate hardware device, one or more computing resources distributedacross hardware devices, and/or may include such aspects as logicalcircuits, embedded circuits, sensors, actuators, input and/or outputdevices, network and/or communication resources, memory resources of anytype, processing resources of any type, and/or hardware devicesconfigured to be responsive to determined conditions to functionallyexecute one or more operations of systems and methods herein.

Network and/or communication resources include, without limitation,local area network, wide area network, wireless, internet, or any otherknown communication resources and protocols. Example and non-limitinghardware and/or computing devices include, without limitation, ageneral-purpose computer, a server, an embedded computer, a mobiledevice, a virtual machine, and/or an emulated computing device. Acomputing device may be a distributed resource included as an aspect ofseveral devices, included as an interoperable set of resources toperform described functions of the computing device, such that thedistributed resources function together to perform the operations of thecomputing device. In certain embodiments, each computing device may beon separate hardware, and/or one or more hardware devices may includeaspects of more than one computing device, for example as separatelyexecutable instructions stored on the device, and/or as logicallypartitioned aspects of a set of executable instructions, with someaspects comprising a part of one of a first computing device, and someaspects comprising a part of another of the computing devices.

A computing device may be part of a server, client, networkinfrastructure, mobile computing platform, stationary computingplatform, or other computing platform. A processor may be any kind ofcomputational or processing device capable of executing programinstructions, codes, binary instructions and the like. The processor maybe or include a signal processor, digital processor, embedded processor,microprocessor or any variant such as a co-processor (math co-processor,graphic co-processor, communication co-processor and the like) and thelike that may directly or indirectly facilitate execution of programcode or program instructions stored thereon. In addition, the processormay enable execution of multiple programs, threads, and codes. Thethreads may be executed simultaneously to enhance the performance of theprocessor and to facilitate simultaneous operations of the application.By way of implementation, methods, program codes, program instructionsand the like described herein may be implemented in one or more threads.The thread may spawn other threads that may have assigned prioritiesassociated with them; the processor may execute these threads based onpriority or any other order based on instructions provided in theprogram code. The processor may include memory that stores methods,codes, instructions and programs as described herein and elsewhere. Theprocessor may access a storage medium through an interface that maystore methods, codes, and instructions as described herein andelsewhere. The storage medium associated with the processor for storingmethods, programs, codes, program instructions or other type ofinstructions capable of being executed by the computing or processingdevice may include but may not be limited to one or more of a CD-ROM,DVD, memory, hard disk, flash drive, RAM, ROM, cache and the like.

A processor may include one or more cores that may enhance speed andperformance of a multiprocessor. In embodiments, the process may be adual core processor, quad core processors, other chip-levelmultiprocessor and the like that combine two or more independent cores(called a die).

The methods and systems described herein, including those relating tothe IoT device registrar 1130, manufacturer 1134, user 1136, third party1138, and/or other entities disclosed herein, may be deployed in part orin whole through a machine that executes computer readable instructionson a server, client, firewall, gateway, hub, router, or other suchcomputer and/or networking hardware. The computer readable instructionsmay be associated with a server that may include a file server, printserver, domain server, internet server, intranet server and othervariants such as secondary server, host server, distributed server andthe like. The server may include one or more of memories, processors,computer readable transitory and/or non-transitory media, storage media,ports (physical and virtual), communication devices, and interfacescapable of accessing other servers, clients, machines, and devicesthrough a wired or a wireless medium, and the like. The methods,programs, or codes as described herein and elsewhere may be executed bythe server. In addition, other devices required for execution of methodsas described in this application may be considered as a part of theinfrastructure associated with the server.

The server may provide an interface to other devices including, withoutlimitation, clients, other servers, printers, database servers, printservers, file servers, communication servers, distributed servers, andthe like. Additionally, this coupling and/or connection may facilitateremote execution of instructions across the network. The networking ofsome or all of these devices may facilitate parallel processing ofprogram code, instructions, and/or programs at one or more locationswithout deviating from the scope of the disclosure. In addition, all thedevices attached to the server through an interface may include at leastone storage medium capable of storing methods, program code,instructions, and/or programs. A central repository may provide programinstructions to be executed on different devices. In thisimplementation, the remote repository may act as a storage medium formethods, program code, instructions, and/or programs.

The methods, program code, instructions, and/or programs may beassociated with a client that may include a file client, print client,domain client, internet client, intranet client and other variants suchas secondary client, host client, distributed client and the like. Theclient may include one or more of memories, processors, computerreadable transitory and/or non-transitory media, storage media, ports(physical and virtual), communication devices, and interfaces capable ofaccessing other clients, servers, machines, and devices through a wiredor a wireless medium, and the like. The methods, program code,instructions, and/or programs as described herein and elsewhere may beexecuted by the client. In addition, other devices required forexecution of methods as described in this application may be consideredas a part of the infrastructure associated with the client.

The client may provide an interface to other devices including, withoutlimitation, servers, other clients, printers, database servers, printservers, file servers, communication servers, distributed servers, andthe like. Additionally, this coupling and/or connection may facilitateremote execution of methods, program code, instructions, and/or programsacross the network. The networking of some or all of these devices mayfacilitate parallel processing of methods, program code, instructions,and/or programs at one or more locations without deviating from thescope of the disclosure. In addition, all the devices attached to theclient through an interface may include at least one storage mediumcapable of storing methods, program code, instructions, and/or programs.A central repository may provide program instructions to be executed ondifferent devices. In this implementation, the remote repository may actas a storage medium for methods, program code, instructions, and/orprograms.

The methods and systems described herein may be deployed in part or inwhole through network infrastructures. The network infrastructure mayinclude elements such as computing devices, servers, routers, hubs,firewalls, clients, personal computers, communication devices, routingdevices and other active and passive devices, modules, and/or componentsas known in the art. The computing and/or non-computing device(s)associated with the network infrastructure may include, apart from othercomponents, a storage medium such as flash memory, buffer, stack, RAM,ROM and the like. The methods, program code, instructions, and/orprograms described herein and elsewhere may be executed by one or moreof the network infrastructural elements.

The methods, program code, instructions, and/or programs describedherein and elsewhere may be implemented on a cellular network havingmultiple cells. The cellular network may either be frequency divisionmultiple access (FDMA) network or code division multiple access (CDMA)network. The cellular network may include mobile devices, cell sites,base stations, repeaters, antennas, towers, and the like.

The methods, program code, instructions, and/or programs describedherein and elsewhere may be implemented on or through mobile devices.The mobile devices may include navigation devices, cell phones, mobilephones, mobile personal digital assistants, laptops, palmtops, netbooks,pagers, electronic books readers, music players and the like. Thesedevices may include, apart from other components, a storage medium suchas a flash memory, buffer, RAM, ROM and one or more computing devices.The computing devices associated with mobile devices may be enabled toexecute methods, program code, instructions, and/or programs storedthereon. Alternatively, the mobile devices may be configured to executeinstructions in collaboration with other devices. The mobile devices maycommunicate with base stations interfaced with servers and configured toexecute methods, program code, instructions, and/or programs. The mobiledevices may communicate on a peer-to-peer network, mesh network, orother communications network. The methods, program code, instructions,and/or programs may be stored on the storage medium associated with theserver and executed by a computing device embedded within the server.The base station may include a computing device and a storage medium.The storage device may store methods, program code, instructions, and/orprograms executed by the computing devices associated with the basestation.

The methods, program code, instructions, and/or programs may be storedand/or accessed on machine readable transitory and/or non-transitorymedia that may include: computer components, devices, and recordingmedia that retain digital data used for computing for some interval oftime; semiconductor storage known as random access memory (RAM); massstorage typically for more permanent storage, such as optical discs,forms of magnetic storage like hard disks, tapes, drums, cards and othertypes; processor registers, cache memory, volatile memory, non-volatilememory; optical storage such as CD, DVD; removable media such as flashmemory (e.g. USB sticks or keys), floppy disks, magnetic tape, papertape, punch cards, standalone RAM disks, Zip drives, removable massstorage, off-line, and the like; other computer memory such as dynamicmemory, static memory, read/write storage, mutable storage, read only,random access, sequential access, location addressable, fileaddressable, content addressable, network attached storage, storage areanetwork, bar codes, magnetic ink, and the like.

Certain operations described herein include interpreting, receiving,and/or determining one or more values, parameters, inputs, data, orother information (“receiving data”). Operations to receive datainclude, without limitation: receiving data via a user input; receivingdata over a network of any type; reading a data value from a memorylocation in communication with the receiving device; utilizing a defaultvalue as a received data value; estimating, calculating, or deriving adata value based on other information available to the receiving device;and/or updating any of these in response to a later received data value.In certain embodiments, a data value may be received by a firstoperation, and later updated by a second operation, as part of thereceiving a data value. For example, when communications are down,intermittent, or interrupted, a first receiving operation may beperformed, and when communications are restored an updated receivingoperation may be performed.

Certain logical groupings of operations herein, for example methods orprocedures of the current disclosure, are provided to illustrate aspectsof the present disclosure. Operations described herein are schematicallydescribed and/or depicted, and operations may be combined, divided,re-ordered, added, or removed in a manner consistent with the disclosureherein. It is understood that the context of an operational descriptionmay require an ordering for one or more operations, and/or an order forone or more operations may be explicitly disclosed, but the order ofoperations should be understood broadly, where any equivalent groupingof operations to provide an equivalent outcome of operations isspecifically contemplated herein. For example, if a value is used in oneoperational step, the determining of the value may be required beforethat operational step in certain contexts (e.g., where the time delay ofdata for an operation to achieve a certain effect is important), but maynot be required before that operation step in other contexts (e.g. whereusage of the value from a previous execution cycle of the operationswould be sufficient for those purposes). Accordingly, in certainembodiments an order of operations and grouping of operations asdescribed is explicitly contemplated herein, and in certain embodimentsre-ordering, subdivision, and/or different grouping of operations isexplicitly contemplated herein.

The methods and systems described herein may transform physical and/oror intangible items from one state to another. The methods and systemsdescribed herein may also transform data representing physical and/orintangible items from one state to another.

The methods and/or processes described above, and steps thereof, may berealized in hardware, program code, instructions, and/or programs or anycombination of hardware and methods, program code, instructions, and/orprograms suitable for a particular application. The hardware may includea dedicated computing device or specific computing device, a particularaspect or component of a specific computing device, and/or anarrangement of hardware components and/or logical circuits to performone or more of the operations of a method and/or system. The processesmay be realized in one or more microprocessors, microcontrollers,embedded microcontrollers, programmable digital signal processors orother programmable device, along with internal and/or external memory.The processes may also, or instead, be embodied in an applicationspecific integrated circuit, a programmable gate array, programmablearray logic, or any other device or combination of devices that may beconfigured to process electronic signals. It will further be appreciatedthat one or more of the processes may be realized as a computerexecutable code capable of being executed on a machine readable medium.

The computer executable code may be created using a structuredprogramming language such as C, an object oriented programming languagesuch as C++, or any other high-level or low-level programming language(including assembly languages, hardware description languages, anddatabase programming languages and technologies) that may be stored,compiled or interpreted to run on one of the above devices, as well asheterogeneous combinations of processors, processor architectures, orcombinations of different hardware and computer readable instructions,or any other machine capable of executing program instructions.

Thus, in one aspect, each method described above, and combinationsthereof, may be embodied in computer executable code that, whenexecuting on one or more computing devices, performs the steps thereof.In another aspect, the methods may be embodied in systems that performthe steps thereof, and may be distributed across devices in a number ofways, or all of the functionality may be integrated into a dedicated,standalone device or other hardware. In another aspect, the means forperforming the steps associated with the processes described above mayinclude any of the hardware and/or computer readable instructionsdescribed above. All such permutations and combinations are intended tofall within the scope of the present disclosure.

While the disclosure has been disclosed in connection with certainembodiments shown and described in detail, various modifications andimprovements thereon will become readily apparent to those skilled inthe art. Accordingly, the present disclosure is not to be limited by theforegoing examples but is to be understood in the broadest senseallowable by law.

What is claimed is:
 1. A method comprising: identifying one or moreBrownfield devices; generating device property data based at least inpart on the one or more Brownfield devices; transmitting, to an Internetof Things (IoT) device registrar server, a registration request thatincludes the device property data; and interpreting one or more Internetof Things Universal Identifiers (IoT UIDs) generated in response to thetransmitting of the registration request.
 2. The method of claim 1,wherein the registration request is for virtual IoT UIDs for the one ormore Brownfield devices.
 3. The method of claim 1, wherein the one ormore IoT UIDs are virtual IoT UIDs.
 4. The method of claim 1, wherein atleast one of identifying the one or more Brownfield devices, generatingthe device property data, or transmitting the registration request areperformed, in part, via a Single Pane of Glass (SPG).
 5. The method ofclaim 4, wherein the SPG is a graphical user interface.
 6. The method ofclaim 5, wherein the SPG is hosted by the IoT device registrar server.7. The method of claim 4, wherein the SPG is an application programminginterface (API).
 8. The method of claim 7, wherein the SPG is hosted bythe IoT device registrar server.
 9. The method of claim 1 furthercomprising: verifying that an entity requesting registration of the oneor more Brownfield devices is authorized to do so.
 10. The method ofclaim 9, wherein verifying is based at least in part on cryptographickeys.
 11. The method of claim 10, wherein the cryptographic keys arebased at least in part on a public key encryption infrastructure. 12.The method of claim 1, wherein the device property data includes atleast one of: an owner identifier value; a manufacturer identifiervalue; a Trusted Platform Module (TPM) Key; a Media Access Control (MAC)address; or a manufacturing serial number.
 13. The method of claim 1further comprising: interpreting, via a device management platform, amessage from the IoT device registrar server that provides confirmationthat the one or more Brownfield devices were successfully registeredwith an IoT device registry corresponding to the IoT device registrarserver.
 14. The method of claim 1, further comprising interpreting adevice event message and updating a record in an IoT device registrybased at least in part on the device event message.
 15. An apparatus,comprising: a display circuit structured to generate a graphical userinterface configured to receive one or more user input command valuescorresponding to device property data for one or more Brownfielddevices; a requestor circuit structured to generate a virtualregistration request that includes the device property data; a requestprovisioning circuit structured to transmit the virtual registrationrequest to an Internet of Things (IoT) device registrar server; anInternet of Things Universal Identifier (IoT UID) processing circuitstructured to interpret one or more virtual IoT UIDs generated by theIoT device registrar server in response to the virtual registrationrequest; and an IoT UID provisioning circuit structured to at least oneof: transmit the one or more virtual IoT UIDs; or display the one ormore virtual IoT UIDs on an electronic display.
 16. The apparatus ofclaim 15 further comprising: a verification circuit structured to verifythat an entity requesting registration of the one or more Brownfielddevices is authorized to do so.
 17. The apparatus of claim 15, whereinthe device property data includes at least one of: an owner identifiervalue; a manufacturer identifier value; a Trusted Platform Module (TPM)Key; a Media Access Control (MAC) address; or a manufacturing serialnumber.
 18. A method, comprising: interpreting, via a deviceregistration request circuit, a virtual registration request that mapsdevice property data to one or more Brownfield devices; generating, viaan Internet of Things Universal Identifier (IoT UID) generation circuit,based at least in part on the virtual registration request, an IoT UIDfor each of the one or more Brownfield devices; generating, via a recordmanagement circuit, a record for each of the IoT UIDs; associating, viathe record management circuit, each of the IoT UIDs with portions of thedevice property data corresponding to a distinct one of the one or moreBrownfield devices; and transmitting, via an IoT UID provisioningcircuit, each of the IoT UIDs.
 19. The method of claim 18 furthercomprising: verifying that an entity requesting registration of the oneor more Brownfield devices is authorized to do so.
 20. The method ofclaim 18, wherein the device property data includes at least one of: anowner identifier value; a manufacturer identifier value; a TrustedPlatform Module (TPM) Key; a Media Access Control (MAC) address; or amanufacturing serial number.